Re: Seg fault in GSIMapCleanMap in gnustep-base-1.24.8

[David Lobron]

Hi David,

>> #0  0xf73fc056 in objc_msg_lookup () from /usr/lib32/libobjc.so.3
>> #1  0xf749e290 in GSIMapCleanMap (map=0x818efb4) at 
>> ../Headers/GNUstepBase/GSIMap.h:1188
>> #2  GSIMapCleanMap (map=0x818efb4) at GSDictionary.m:117
>> #3  GSIMapEmptyMap (map=0x818efb4) at ../Headers/GNUstepBase/GSIMap.h:1219
>> #4  -[GSDictionary dealloc] (self=0x818efb0, _cmd=0xf783c5f0) at 
>> GSDictionary.m:118
>> #5  0xf75c0395 in -[NSObject release] (self=0x818efb0, _cmd=0xf7f84528) at 
>> NSObject.m:2105
>> #6  0xf7c28290 in -[Configuration dealloc] (self=0x819ed18, _cmd=0xf7f7d7a0) 
>> at Configuration.m:715
>> 
>> The code that triggers the error is in my dealloc method - I'm calling 
>> "release" on an NSDictionary object.  The crash doesn't happen every time 
>> under gdb, but it does occur reliably outside gdb.
> 
> This looks like it’s trying to release an object that’s already been 
> destroyed.  What happens if you run the program with valgrind or NSZombie?

I tried Valgrind, and it did indeed report an invalid read of size 4.  It also 
reports a double free:

==24092==  Address 0xab6cd98 is 16 bytes inside a block of size 68 free'd
==24092==    at 0x48CE06C: free (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==24092==    by 0x8AA455A: default_free (NSZone.m:157)
==24092==    by 0x8AA6784: NSZoneFree (NSZone.m:2148)
==24092==    by 0x89F8F40: _i_NSObject__dealloc (NSObject.m:863)
==24092==    by 0x8AAD0FC: _i_GSFileHandle__dealloc (GSFileHandle.m:367)
==24092==    by 0x89F9394: _i_NSObject__release (NSObject.m:2105)
==24092==    by 0x6C00E6B: _i_MyDaemonPrivateVars__dealloc (MyDaemon.m:153)

The code at MyDaemon.m:153 is releasing an NSFileHandle, which I'm allocating 
with "initWithFileDescriptor:fd closeOnDealloc:YES".  

This code has been around a long time, and only crashes with this newer 
gnustep-base.  Did any behavior change in NSFileHandle that might cause a 
double free?

Thanks!

--David

smime.p7s
Description: S/MIME cryptographic signature