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

[David Lobron]

Hi David,

>> 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?
> 
> Not that I’m aware of, but NSFileHandle is a very small class and memory 
> reuse may have masked the bug.  The easiest way of tracking this is probably 
> to add a category on GSFileHandle that adds trivial retain and release 
> methods that just call the superclass implementation and stick breakpoints on 
> them.  You probably have an unbalanced release somewhere (possibly in GNUstep 
> code).

I tried this, and I did not see an unbalanced release.  Actually, I'm now 
thinking that Valgrind was pointing me in the wrong direction.  The stack trace 
after my code seg faults suggests that GSArray might be to blame:

#0  0xf73fc056 in objc_msg_lookup () from /usr/lib32/libobjc.so.3
#1  0xf74938cf in -[GSInlineArray dealloc] (self=0x80ee948, _cmd=0xf783c5f0) at 
GSArray.m:402
#2  0xf75c0405 in -[NSObject release] (self=0x80ee948, _cmd=0xf7806130) at 
NSObject.m:2105
#3  0xf74eb716 in -[NSArrayEnumerator dealloc] (self=0x80d16d0, 
_cmd=0xf783c5f0) at NSArray.m:2612
#4  0xf75c0405 in -[NSObject release] (self=0x80d16d0, _cmd=0xf7808960) at 
NSObject.m:2105
#5  0xf74f3923 in -[NSAutoreleasePool emptyPool] (self=0x80bef18, 
_cmd=0xf7808968) at NSAutoreleasePool.m:689
#6  0xf74f3a84 in -[NSAutoreleasePool dealloc] (self=0x80bef18, 
_cmd=0xf7808958) at NSAutoreleasePool.m:729
#7  0xf74f33e9 in -[NSAutoreleasePool release] (self=0x80bef18, _cmd=0x804d8f0) 
at NSAutoreleasePool.m:722

The code around GSArray.m:402 is looping through _contents_array, and releasing 
each item individually.  I tried adding some print statements there and 
stepping through in a debugger, but I did not see anything unbalanced.

I also sometimes get this stack:

#0  0xf73fc056 in objc_msg_lookup () from /usr/lib32/libobjc.so.3
#1  0xf74b31a9 in GSIMapCleanMap (map=0x80e875c) at 
../Headers/GNUstepBase/GSIMap.h:1184
#2  GSIMapCleanMap (map=0x80e875c) at GSSet.m:190
#3  GSIMapEmptyMap (map=0x80e875c) at ../Headers/GNUstepBase/GSIMap.h:1219
#4  -[GSSet dealloc] (self=0x80e8758, _cmd=0xf783c610) at GSSet.m:191
#5  0xf75c03d5 in -[NSObject release] (self=0x80e8758, _cmd=0xf7f84528) at 
NSObject.m:2105
#6  0xf7c282a8 in -[Configuration dealloc] (self=0x80d2f98, _cmd=0x804d788) at 
Configuration.m:716

I'm wondering if memory is corrupted somewhere, such that the crash happens in 
different places.

--David

smime.p7s
Description: S/MIME cryptographic signature