bugGNUstep - Bugs: bug #26958, debugapp crashes on base svn head

Group
 
 

bug #26958: debugapp crashes on base svn head

Submitter:  Leigh Smith <leighsmith>
Submitted:  Sat 04 Jul 2009 09:34:35 AM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 04 Jul 2009 05:37:05 PM UTC, comment #2: 

Yes it seems it is a conflict between two different versions of gnustep-base that is the cause of the problem.

Leigh Smith <leighsmith>
Sat 04 Jul 2009 10:18:31 AM UTC, comment #1: 

There's no detail of the release version and/or operating system but the main text of the report is almost certainly wrong.

If GSCompatibility was involved, then we would be talking about the Apple foundation, and the stacktrace shows we aren't.

So, the giveaway in the stacktrace really is:

#2 0xb77f0fe5 in NSMapGet (table=0x0, key=0xb72be160)
at NSConcreteMapTable.m:554

This shows that we have a null map table ... and that can't happen since the map table is created when NSProcessInfo is initialized, and NSProcessInfo must have been initialised before this point in the code.

So ... how can we have a situation where the map table has been initialized, but we get here and its nul?
There are only two ways I know ... one is if something has overwritten the memory between initialisation and the point when it's used.

The other (by far most likely) is if two versions of the library are linked into the application and the order in which things have happened means that one version of the NSProcessInfo class initialized the table, but another version of the class (with a different version of the table) is being used.

The solution, if this is the case, is to ensure that only one version of the library exists on the system, and ensure that all bundles etc are linked with it.

Q. is it possible for us to somehow detect when an application loads in bundles which use conflicting libraries or classes?  Dynamic loading generally permits separate copies of libraries, but this is a problem if they contain ObjC classes which all get connected to the runtime library.

Richard Frith-Macdonald <CaS>
Group Member
Sat 04 Jul 2009 09:34:35 AM UTC, original submission:  

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)

Leigh Smith <leighsmith>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Updated the item)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by leighsmith (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-05 FredKiefer StatusNone Invalid
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code