discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fred Kiefer
Subject: Re: Seg fault in GSIMapCleanMap in gnustep-base-1.24.8
Date: Tue, 4 Aug 2015 09:48:50 +0200

Hi David,

you wrote that this is problem happens in a unit test. Would it be possible to 
strip down the code enough to send it to David or me?

Fred

On the road

Am 03.08.2015 um 22:24 schrieb David Lobron <dlobron@akamai.com>:

> 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
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep



reply via email to

[Prev in Thread] Current Thread [Next in Thread]