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

[David Chisnall]

On 30 Jul 2015, at 17:56, David Lobron <dlobron@akamai.com> wrote:
> 
> 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).

David

-- Sent from my Difference Engine