[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