[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: big memory leak in GSString
From: |
Tom Davie |
Subject: |
Re: big memory leak in GSString |
Date: |
Mon, 7 Jan 2013 22:28:13 +0000 |
On 7 Jan 2013, at 22:15, Pirmin Braun <address@hidden> wrote:
> Am Mon, 7 Jan 2013 22:00:40 +0000
> schrieb Tom Davie <address@hidden> :
>
>> Retain count means nothing. It may well have a retain count of 2, but be in
>> the autorelease pool twice. Can you confirm that these actually are never
>> released, and provide a small test case that demonstrates it?
>>
>
> I've tried this, just before "(imps[hash])(anObject, releaseSel);":
>
> if([[[anObject
> class]description]isEqualToString:@"GSCSubString"]){while([anObject
> retainCount] > 1)[anObject release];}
>
> now if the GSCSubString was twice in the autorelease pools, it would have
> crashed on being released by the second pool.
Would it? The behaviour when sending messages to deallocated memory is
entirely undefined. It may crash, it may carry on regardless. If the memory
hasn't been modified by anything else, carry on regardless is more likely.
> Also I did some debugging with gdb with breakpoints on [NSAutoreleasePool
> alloc] and dealloc to make sure, there are no other pools involved. And the
> App is singlethreaded.
Instead, simply try to reduce this to a simple test case in which the string is
not deallocated, yet all autorelease pools have been popped, and all
allocs/retains balanced.
Thanks
Tom Davie
- big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString,
Tom Davie <=
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Tom Davie, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/07
- Re: big memory leak in GSString, David Chisnall, 2013/01/08
- Re: big memory leak in GSString, Fred Kiefer, 2013/01/08
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/08
- Re: big memory leak in GSString, David Chisnall, 2013/01/08
- Re: big memory leak in GSString, Pirmin Braun, 2013/01/08
- Re: big memory leak in GSString, Richard Frith-Macdonald, 2013/01/08