gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help needed with debugging


From: Fred Kiefer
Subject: Re: Help needed with debugging
Date: Sat, 22 Nov 2008 20:39:03 +0100
User-agent: Thunderbird 2.0.0.17 (X11/20080922)

Thank you David,

it must have been something like the last possibility you explained. I
had already recompiled base and the application, but this gave no
difference. After recompiling gui and back as well things worked again.
So most likely my code loaded two versions of base at once and did
strange things with them.

In my /usr/GNUstep/System/Library/Libraries/ (yes, I am a bit old
fashioned, so what?) directory I have (leaving out hundreds of very old
files):

lrwxrwxrwx 1 root root       23 22. Nov 18:08 libgnustep-base.so ->
libgnustep-base.so.1.15
lrwxrwxrwx 1 root root       25 22. Nov 18:08 libgnustep-base.so.1.15 ->
libgnustep-base.so.1.15.4
-rwxr-xr-x 1 root root  7668515  5. Nov 2007  libgnustep-base.so.1.15.0
-rwxr-xr-x 1 root root  7753696  1. Jan 2008  libgnustep-base.so.1.15.1
-rwxr-xr-x 1 root root  7835808  6. Mär 2008  libgnustep-base.so.1.15.2
-rwxr-xr-x 1 root root  7899009  7. Jun 15:43 libgnustep-base.so.1.15.3
-rwxr-xr-x 1 root root  7428389 22. Nov 18:08 libgnustep-base.so.1.15.4
lrwxrwxrwx 1 root root       25 18. Nov 00:16 libgnustep-base.so.1.17 ->
libgnustep-base.so.1.17.0
-rwxr-xr-x 1 root root  7424202 18. Nov 00:16 libgnustep-base.so.1.17.0

Looks like somebody downgraded GNUstep base from 1.17 to 1.15.4. Was
this done on purpose?

Fred

David Chisnall wrote:
> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]