• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Autoreleasepool problems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Autoreleasepool problems


  • Subject: Re: Autoreleasepool problems
  • From: Kay Roepke <email@hidden>
  • Date: Wed, 19 Jul 2006 20:28:35 +0200


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@hidden>
classdump Software


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Follow-Ups:
    • Re: Autoreleasepool problems
      • From: Kay Roepke <email@hidden>
    • Re: Re: Autoreleasepool problems
      • From: "Shawn Erickson" <email@hidden>
References: 
 >Autoreleasepool problems (From: Kay Roepke <email@hidden>)
 >Re: Autoreleasepool problems (From: "Shawn Erickson" <email@hidden>)

  • Prev by Date: Re: Writing application without Interface Builder
  • Next by Date: Re: Centering an NSAttributedString in a line in a view
  • Previous by thread: Re: Autoreleasepool problems
  • Next by thread: Re: Re: Autoreleasepool problems
  • Index(es):
    • Date
    • Thread