[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #26958] debugapp crashes on base svn head
From: |
Leigh Smith |
Subject: |
[bug #26958] debugapp crashes on base svn head |
Date: |
Sat, 04 Jul 2009 09:34:36 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11) Gecko/2009061212 Iceweasel/3.0.6 (Debian-3.0.6-1) |
URL:
<http://savannah.gnu.org/bugs/?26958>
Summary: debugapp crashes on base svn head
Project: GNUstep
Submitted by: leighsmith
Submitted on: Sat 04 Jul 2009 09:34:35 AM GMT
Category: Base/Foundation
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
Hello,
I'm encountering problems attempting to debug applications using the head of
the repository. The application runs correctly with openapp but crashes when
run within gdb as the stack dump shows below.
The problem seems to be that GSDebugSet defined in NSProcessInfo checks if
_debug_set == nil and if so, messages the -[NSProcessInfo debugSet], which as
defined within NSProcessInfo.m, does not change _debug_set, causing the
segfault. There is also GSDebugSet defined within GSCompatibility.m, which has
a definition of debugSet that modifies _debug_set. Clearly that method should
be run, but why should there be two GSDebugSet() functions defined? The only
difference between the two functions is the check if debugTemporarilyDisabled
is set. Since debugSet is defined in NSProcessInfo and
NSProcessInfo(GSCompatibility), the earlier defined method seems to override
the one defined in the category. Perhaps I'm not understanding when the
debugSet method in NSProcessInfo should be run?
(gdb) run
Starting program: /usr/GNUstep/Local/Applications/PianoRoll.app/PianoRoll
[Thread debugging using libthread_db enabled]
[New Thread 0xb65426c0 (LWP 3742)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb65426c0 (LWP 3742)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xb78a974b in GSDebugSet (level=0xb7a75880) at NSProcessInfo.m:1449
#2 0xb77f0fe5 in NSMapGet (table=0x0, key=0xb72be160)
at NSConcreteMapTable.m:554
#3 0xb787634a in GSNumberInfoFromObject (o=0x90be630) at NSNumber.m:97
#4 0xb708c191 in +[NSNumber initialize] (self=0xb72dbda0, _cmd=0xb7308e68)
at NSNumber.m:205
#5 0xb76cd625 in ?? () from /usr/lib/libobjc.so.2
#6 0xb76cd82e in objc_msg_lookup () from /usr/lib/libobjc.so.2
#7 0xb7889814 in ExtractValuesFromConfig (config=0x90bdf00)
at NSPathUtilities.m:544
#8 0xb788b57b in InitialisePathUtilities () at NSPathUtilities.m:885
#9 0xb788ddd3 in NSSearchPathForDirectoriesInDomains (directoryKey=5,
domainMask=65535, expandTilde=1 '\001') at NSPathUtilities.m:1759
#10 0xb77dc4a2 in +[NSBundle(GNUstep) bundleForLibrary:version:] (
self=0xb72b7940, _cmd=0xb72b7ba0, libraryName=0x901bb00,
interfaceVersion=0xb72b70c0) at NSBundle.m:2365
#11 0xb6ff17d0 in +[NSBundle initialize] (self=0xb72b7940, _cmd=0xb7308e68)
at NSBundle.m:821
#12 0xb76cd625 in ?? () from /usr/lib/libobjc.so.2
#13 0xb76cd82e in objc_msg_lookup () from /usr/lib/libobjc.so.2
#14 0xb7c994e7 in NSApplicationMain (argc=1, argv=0xbfdfde34) at
Functions.m:64
#15 0x08049002 in main (argc=Cannot access memory at address 0x0
) at PianoRoll_main.m:8
(gdb)
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?26958>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [bug #26958] debugapp crashes on base svn head,
Leigh Smith <=