MallocDebug oddities /w GNUstep on Darwin
Lars Sonchocky-Helldorf
Am Mittwoch den, 17. Juli 2002, um 09:47, schrieb Markus Hitter:
>
> Am Mittwoch den, 17. Juli 2002, um 02:04, schrieb Lars
> Sonchocky-Helldorf:
>
>> [ dozens of duplicates removed ... ]
>> symbol _malloc_zone_malloc used from dynamic library
>> /usr/lib/libSystem.dylib(malloc.o) not from earlier dynamic library
>> /opt/GNUstep/System/Libraries/powerpc/darwin5/nx-gnu-
>> gnu/libgnustep-base_d.dylib(debug_malloc.o)
>> [ ... again dozens ... ]
>
> This makes me wonder why malloc stuff is linked (statically?) into
> GNUstep base library. But as the linker chooses the right one, it
> doesn't really matter at the moment.
That was just me causing this (because MallocDebugs Help said so)
However there is also libMallocDebug.A.dylib which I tried today:
[localhost:~] lars% locate libMallocDebug
/usr/lib/libMallocDebug.a
/usr/lib/libMallocDebug.A.dylib
I changed base.make again for that purpose:
CONFIG_SYSTEM_LIBS += -lz -lMallocDebug.A
but the warnings during linking libgnustep-base_d.dylib remain:
ld: warning multiple definitions of symbol _malloc_zone_print
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
definition of _malloc_zone_print
/usr/lib/libSystem.dylib(malloc.o) definition of _malloc_zone_print
ld: warning multiple definitions of symbol _malloc_zone_malloc
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
definition of _malloc_zone_malloc
/usr/lib/libSystem.dylib(malloc.o) definition of _malloc_zone_malloc
.
.
.
and the like. I don't know if those warnings are something to consider
important. The same with the warnings when building the tools, for
instance dictionary (my favorite):
symbol _malloc used from dynamic library
/usr/lib/libSystem.dylib(malloc.o) not from earlier dynamic library
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
symbol _malloc_zone_print used from dynamic library
/usr/lib/libSystem.dylib(malloc.o) not from earlier dynamic library
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
.
.
.
and so on. However I got the following "hint" from ld but don't what
exactly it implies:
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may
result in errors or different symbols being used
On debugging dictionary using gdb things went really strange. Obviously
somehow GNUstep and Cocoa got intermixed somehow:
(gdb) run
Starting program: /Volumes/Data/Projekte/GNUstep-
Darwin/core/base/Examples/shared_debug_obj/powerpc/darwin5/nx-gnu-
gnu/dictionary
[Switching to process 6198 thread 0x1603]
Reading symbols for shared libraries ....... done
objc: Both /opt/GNUstep/System/Libraries/powerpc/darwin5/nx-gnu-
gnu/libgnustep-base_d.dylib and
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
have implementations of class NSMutableArray.
objc: Using implementation from
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.
objc: Both /opt/GNUstep/System/Libraries/powerpc/darwin5/nx-gnu-
gnu/libgnustep-base_d.dylib and
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
have implementations of class NSArray.
objc: Using implementation from
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.
.
.
.
and badly enough it is using Cocoa's implementation. If I would only
know how to stop gdb from doing this. Never the less, dictionary still
crashes, and the backtrace is a potpourri of Cocoa and GNUstep:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x70813884 in -[NSConstantString getCharacters:range:] ()
(gdb) bt
#0 0x70813884 in -[NSConstantString getCharacters:range:] ()
#1 0x7016918c in _CFStringAppendFormatAndArgumentsAux ()
#2 0x70168e68 in _CFStringCreateWithFormatAndArgumentsAux ()
#3 0x7083eedc in -[NSPlaceholderString
initWithFormat:locale:arguments:] ()
#4 0x708359e8 in -[NSString initWithFormat:arguments:] ()
#5 0x70852a1c in +[NSException raise:format:arguments:] ()
#6 0x708529ac in +[NSException raise:format:] ()
#7 0x7088bef4 in -[NSObject forward::] ()
#8 0x706bb250 in _objc_msgForward ()
#9 0x7016b164 in CFStrIsUnicode ()
#10 0x7016af88 in __CFStringReplace ()
#11 0x7016af30 in CFStringAppend ()
#12 0x7016a1e8 in _CFStringAppendFormatAndArgumentsAux ()
#13 0x70168e68 in _CFStringCreateWithFormatAndArgumentsAux ()
#14 0x7083f94c in NSLogv ()
#15 0x7084b3b4 in NSLog ()
.
looped several times
.
#2146 0x7083f94c in NSLogv ()
#2147 0x7084b3b4 in NSLog ()
#2148 0x708c6660 in _NSRaiseError ()
#2149 0x708788b8 in -[NSException raise] ()
#2150 0x70852a50 in +[NSException raise:format:arguments:] ()
#2151 0x708529ac in +[NSException raise:format:] ()
#2152 0x7088bef4 in -[NSObject forward::] ()
#2153 0x706bb250 in _objc_msgForward ()
#2154 0x7016b164 in CFStrIsUnicode ()
#2155 0x7016af88 in __CFStringReplace ()
#2156 0x7016af30 in CFStringAppend ()
#2157 0x7016a1e8 in _CFStringAppendFormatAndArgumentsAux ()
#2158 0x70168e68 in _CFStringCreateWithFormatAndArgumentsAux ()
#2159 0x7083f94c in NSLogv ()
#2160 0x7084b3b4 in NSLog ()
#2161 0x708c6660 in _NSRaiseError ()
#2162 0x708788b8 in -[NSException raise] ()
#2163 0x70852a50 in +[NSException raise:format:arguments:] ()
#2164 0x708529ac in +[NSException raise:format:] ()
#2165 0x7088bef4 in -[NSObject forward::] ()
#2166 0x706bb250 in _objc_msgForward ()
#2167 0x00633084 in _gnu_process_args (argc=1, argv=0xbffff3c4,
env=0xbffff3cc) at NSProcessInfo.m:181
#2168 0x006335bc in main (argc=1, argv=0xbffff3c4, env=0xbffff3cc) at
NSProcessInfo.m:539
#2169 0x000028f0 in _start ()
#2170 0x00002720 in start ()
(gdb) quit
> Markus
greetings, Lars
Markus Hitter
Am Freitag den, 19. Juli 2002, um 00:12, schrieb Lars
Sonchocky-Helldorf:
> #15 0x7084b3b4 in NSLog ()
> .
> . looped several times
> .
> #2146 0x7083f94c in NSLogv ()
> #2147 0x7084b3b4 in NSLog ()
> #2148 0x708c6660 in _NSRaiseError ()
> #2149 0x708788b8 in -[NSException raise] ()
The problem is, -[NSException raise] uses a method which might
raise an Exception yet again -> endless loop.
I told about this on March 20th on the GNUstep bug list but
obviously neither the patch provided there nor any other
solution made it into the sources.
It would be a good idea to remove usage of NSString in
-[NSException raise] and use fprintf() instead, IMHO. Any
comments on this?
Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/
Nicola Pero
> > #15 0x7084b3b4 in NSLog ()
> > .
> > . looped several times
> > .
> > #2146 0x7083f94c in NSLogv ()
> > #2147 0x7084b3b4 in NSLog ()
> > #2148 0x708c6660 in _NSRaiseError ()
> > #2149 0x708788b8 in -[NSException raise] ()
>
> The problem is, -[NSException raise] uses a method which might
> raise an Exception yet again -> endless loop.
Ok yes - it's a bug but ... Was the stack trace for gnustep-base or for
the Apple Foundation ?
Since there is no _NSRaiseError in gnustep, I think this stack trace is
from Apple's Foundation, and the bug is in their code, not ours.
> I told about this on March 20th on the GNUstep bug list but
> obviously neither the patch provided there nor any other
> solution made it into the sources.
>
> It would be a good idea to remove usage of NSString in
> -[NSException raise] and use fprintf() instead, IMHO. Any
> comments on this?
Looking at the gnustep-base Source, there is no NSLog in NSException - the
gnustep's _NSFoundationUncaughtExceptionHandler() is *already* using
fprintf.
So I think your remark/change/patch did make it into the gnustep-base
sources. It didn't make it into Apple's Foundation - but that's not our
problem :-)
Nicola Pero
> > I told about this on March 20th on the GNUstep bug list but
> > obviously neither the patch provided there nor any other
> > solution made it into the sources.
> >
>
> gnustep's _NSFoundationUncaughtExceptionHandler() is *already* using
> fprintf.
>
> So I think your remark/change/patch did make it into the gnustep-base
> sources. It didn't make it into Apple's Foundation - but that's not our
> problem :-)
I went to search for your original post, and I see you suggested a totally
unrelated change to prevent a different type of recursive exceptions ...
which has not indeed made it into the library.
The problem I can see with your patches is that ... it's a very
interesting problem, but I don't see a good solution ... the best solution
I can see is ... to leave it as it is :-)
Trying just to prevent all recursive exceptions is not a solution, since
it would also prevent legitimate recursive exceptions - such as for
example if NSException +raise:format:arguments: is called with invalid
format, arguments, and during raising of the exception, the invalid
format, arguments cause another (different) exception to be raised because
of the invalid format, arguments. I think it's absolutely legimitate to
raise the recursive exception here (and recursion would not be infinite).
Trying to store the latest recursive exception name and preventing any
recursive exception with the name is no solution either, since a
legitimate recursive exception might have the same name, yet be a
different exception. Also, you would need to lock the saved last name
against thread problems, and then are we sure we are not causing more
problems than we are fixing by getting into this complication ? :-)
The only case I can imagine in which you get the infinite recursive
exception is if your gnustep-base library is broken - actually the only
real case I can think of is if your NSString class is totally broken - a
basic NSConstantString problem ? - in which case the program would
normally not even start :-)
Anyway - if you think you really have a great patch to work around this
problem (and you can show me a real case - different from a broken
NSConstantString - where it would prevent a crash due to an infinite stack
loop), please let me know - I'll be happy to have it applied.
Lars Sonchocky-Helldorf
Am Freitag den, 19. Juli 2002, um 13:08, schrieb Nicola Pero:
>
>>> #15 0x7084b3b4 in NSLog ()
>>> .
>>> . looped several times
>>> .
>>> #2146 0x7083f94c in NSLogv ()
>>> #2147 0x7084b3b4 in NSLog ()
>>> #2148 0x708c6660 in _NSRaiseError ()
>>> #2149 0x708788b8 in -[NSException raise] ()
>>
>> The problem is, -[NSException raise] uses a method which might
>> raise an Exception yet again -> endless loop.
>
> Ok yes - it's a bug but ... Was the stack trace for gnustep-base or for
> the Apple Foundation ?
>
> Since there is no _NSRaiseError in gnustep, I think this stack trace is
> from Apple's Foundation, and the bug is in their code, not ours.
Nicola is right here, at #2166 the stack trace is switching from GNUstep
to Apple's Foundation (as you can see from the missing "at
NSxxx.m:lineNumber".
#2165 0x7088bef4 in -[NSObject forward::] ()
#2166 0x706bb250 in _objc_msgForward ()
#2167 0x00633084 in _gnu_process_args (argc=1, argv=0xbffff3c4,
env=0xbffff3cc) at NSProcessInfo.m:181
#2168 0x006335bc in main (argc=1, argv=0xbffff3c4, env=0xbffff3cc) at
NSProcessInfo.m:539
#2169 0x000028f0 in _start ()
#2170 0x00002720 in start ()
My question was how to keep gdb or MallocDebug from using Apple's
Foundation and use GNUstep-base instead:
(gdb) run
Starting program: /Volumes/Data/Projekte/GNUstep-
Darwin/core/base/Examples/shared_debug_obj/powerpc/darwin5/nx-gnu-
gnu/dictionary
[Switching to process 6198 thread 0x1603]
Reading symbols for shared libraries ....... done
objc: Both /opt/GNUstep/System/Libraries/powerpc/darwin5/nx-gnu-
gnu/libgnustep-base_d.dylib and
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
have implementations of class NSMutableArray.
objc: Using implementation from
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.
and so on for every Class.
Maybe there is no way (I am just not experienced enough to know that) to
keep gdb, whatever from "Using implementation from
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation.".
but also then please tell me. Then I would have to go other ways.
What about those warnings:
/usr/bin/ld: warning multiple definitions of symbol _malloc_zone_print
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
definition of _malloc_zone_print
/usr/lib/libSystem.dylib(malloc.o) definition of _malloc_zone_print
/usr/bin/ld: warning multiple definitions of symbol _malloc_zone_malloc
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
definition of _malloc_zone_malloc
or
symbol _malloc used from dynamic library
/usr/lib/libSystem.dylib(malloc.o) not from earlier dynamic library
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
symbol _malloc_zone_print used from dynamic library
/usr/lib/libSystem.dylib(malloc.o) not from earlier dynamic library
/usr/lib/libMallocDebug.A.dylib(ProjectBuilderMasterObjectFile.o)
are they relevant? Must/can there something be done?
What about:
Linking test_tool dictionary ...
/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may
result in errors or different symbols being used
Thanks and greetings, Lars