Re: Help needed with debugging

[David Chisnall]

Hey Fred,

When I've seen this kind of error before in gdb, it's been due to  
mismatches between linker and debug symbols.  GNUstep Make seems to  
have a few bugs which I haven't been able to track down which means it  
doesn't always rebuild all objects that depend on a modified header,  
which can allow these to be misaligned.  Does the same error appear  
with a clean build of both GNUstep and the ?

The other possible option is that the static is not being committed to  
memory before the function call.  In this case, it would be a bug in  
the interprocedural analysis.  By the way, is there a reason that  
GSNumberInfoFromObject() isn't static?  If you are accidentally  
linking against two copies of GNUstep then this is an alternate cause  
- because the function is not static the method may be calling the  
version from the other file, meaning that both files will be seeing  
different versions of the static, one of which will have been  
initialised, one won't.

David

On 22 Nov 2008, at 17:29, Fred Kiefer wrote:

> I am getting rather strange results when running a GNUstep test
> application. Here my gdb buffer:
>
> address@hidden:~/GNUstep/Examples/TestApp3a> openapp --debug ./ 
> TestApp3.app/
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show  
> copying"
> and "show warranty" for details.
> This GDB was configured as "i586-suse-linux"...
> (gdb) r
> Starting program:
> /home/fred/GNUstep/Examples/TestApp3a/TestApp3.app/TestApp3
> [Thread debugging using libthread_db enabled]
> [New Thread 0xb6fd46c0 (LWP 21986)]
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb6fd46c0 (LWP 21986)]
> 0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0xb7980a64 in NSMapGet (table=0x0, key=0xb75f1de0) at  
> NSMapTable.m:364
> #2  0xb79869a6 in GSNumberInfoFromObject (o=0x80f80b8) at NSNumber.m: 
> 97
> #3  0xb73fd845 in +[NSNumber initialize] (self=0xb760fd20,
>    _cmd=0xb763cf08) at NSNumber.m:205
> #4  0xb77d36c5 in ?? () from /usr/lib/libobjc.so.2
> #5  0xb77d38ce in objc_msg_lookup () from /usr/lib/libobjc.so.2
> #6  0xb799908b in ExtractValuesFromConfig (config=0x80fd620)
>    at NSPathUtilities.m:531
> #7  0xb799ae1c in InitialisePathUtilities () at NSPathUtilities.m:872
> #8  0xb799d82f in NSSearchPathForDirectoriesInDomains (
>    directoryKey=NSLibraryDirectory, domainMask=NSAllDomainsMask,
>    expandTilde=1 '\001') at NSPathUtilities.m:1746
> #9  0xb78f0986 in +[NSBundle(GNUstep) bundleForLibrary:version:] (
>    self=0xb75eb5a0, _cmd=0xb75eb820, libraryName=0x8072930,
>    interfaceVersion=0xb75ead20) at NSBundle.m:2331
> #10 0xb736253d in +[NSBundle initialize] (self=0xb75eb5a0,
>    _cmd=0xb763cf08) at NSBundle.m:841
> #11 0xb77d36c5 in ?? () from /usr/lib/libobjc.so.2
> #12 0xb77d38ce in objc_msg_lookup () from /usr/lib/libobjc.so.2
> ---Type <return> to continue, or q <return> to quit---q
> Quit
> (gdb) up 2
> #2  0xb79869a6 in GSNumberInfoFromObject (o=0x80f80b8) at NSNumber.m: 
> 97
> 97        info = (GSNumberInfo*)NSMapGet (numberMap, (void*)c);
> (gdb) p numberMap
> $1 = (NSMapTable *) 0x0
> (gdb) up
> #3  0xb73fd845 in +[NSNumber initialize] (self=0xb760fd20,
>    _cmd=0xb763cf08) at NSNumber.m:205
> 205           info =  
> GSNumberInfoFromObject(AUTORELEASE([boolNumberClass
> alloc]));
> (gdb) p numberMap
> $2 = (NSMapTable *) 0x8101ff8
>
>
> So there is a static variable numberMap in NSNumber.m that is at once
> set and not set. Does anybody out there have an explanation for this  
> and
> even better a workaround for this problem?
>
> This same test application used to work and other applications still
> continue to work well. Although any real problem in base should break
> them all.
>
> Fred
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev