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: David Chisnall
Subject: Re: Seg fault in GSIMapCleanMap in gnustep-base-1.24.8
Date: Tue, 4 Aug 2015 08:40:58 +0100

On 3 Aug 2015, at 21:24, David Lobron <dlobron@akamai.com> wrote:
> 
> 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.

Again, this looks *very* like an unbalanced release.  Both cases are trying to 
release an object that is already released.  Given the number of places where 
GSInlineArray and GSIMap are used (i.e. every nontrivial GNUstep application), 
it seems quite unlikely that they are responsible.

Is the address of the object that is being sent the release message the same in 
both cases?  Without looking at the code, I would guess that you have an 
NSFileHandle instance that you are storing in an ivar of MyDaemonPrivateVars 
and in an NSArray and an NSDictionary, and you are not retaining it when you 
assign it to the ivar.  Please can you show me the code for how you create the 
NSFileHandle instance and how you assign it to the ivar?

Alternatively, run your code through the ARC migration tool and see if the 
problem goes away.

David

-- Sent from my STANTEC-ZEBRA




reply via email to

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