Re: Autoreleasepool problems

FROM : Kay Roepke
DATE : Wed Jul 19 20:28:35 2006

On 19. Jul 2006, at 20:11 Uhr, Shawn Erickson wrote:

> If you call any code from the Cocoa framework (etc.) code in the
> framework may send a retain following at some point by a release or
> autorelease. In other words even you don't send an object an
> autorelease some framework code may send it an autorelease message.


That's why I overrode autorelease to double-check where it might come 
from. It isn't called.

> I think you are attacking the issue in the wrong way... don't attempt
> to peer into autorelease pools or retain counts because you have poor
> visibility of what framework code does.


Normally I wouldn't do that, but since I'm not seeing any autorelease 
calls at all, that was
the last resort...

> Instead try to understand exactly which object is being over released
> and look at that objects life time in code and by using things like
> ObjectAlloc.app. Make sure to enable NSZombie support as well.


I should've said that. ObjectAlloc tells me of one allocation event, 
one retain (both from my own
code - alloc/init) and one free event (coming out of the autorelease 
pool) before the shell tool gets a SIGTRAP.
NSZombie tells me that NSPopAutoreleasePool is sending release to 
dealloced instance. Which I happen to know
already :(
The problem is that the EOFToken instance shouldn't be in an 
autorelease pool in the first place. I for sure didn't
put it there, and I can't figure out how it might end up there. I 
have only one pool, in main. Thus my reasoning is that
nothing should change in that pool behind my back, see below.

> Also recall that the same address in memory can be reused so if you
> have a stale pointer (which easily happens if you over release
> something) then the pointer can end up pointer at an unrelated
> object... which can confuse you attempts to debug things (NSZombie can
> help with that).


ObjectAlloc doesn't show me any overreleased objects at all. 
Everything is balanced, save the extra entry in the pool.
I'm a bit at loss here. I know for sure that I'm not releasing the 
EOF token, since it is supposed to be static anyway.

-k
--
Kay Röpke <<email_removed>>
classdump Software