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