Re: My bug or Apple's?
Re: My bug or Apple's?
- Subject: Re: My bug or Apple's?
- From: Günther Blaschek <email@hidden>
- Date: Fri, 12 Nov 2004 12:32:50 +0100
On 12. Nov 2004, at 11:55, email@hidden wrote:
So what's the best solution here?
(a) Wrap this destructor with an autorelease pool
(b) Find a way to release the NSImages before exit() is called
(c) File a bug with Apple, since they are assuming an autorelease
pool exists
There are a number of objects in the Cocoa frameworks that assume an
autorelease pool is in place at all times. I would say that is not a
bug. If your application is calling -[NSApp terminate], you should
probably just wrap that in an autorelease pool.
I'm not sure that this will do the trick, as terminate will just clean
up the most recent autorelease pool in which you wrapped it. This will
essentially be a no-op, since the autorelease pool will be empty.
OK, terminate will probably not crash, but nothing will get cleaned up,
since you created all your objects outside the scope of this
autorelease pool.
When you work with Cocoa objects, you will typically use many object
creation methods that return autoreleased objects. If no autorelease
pool is in place, you are just lucky that this works now, and I would
not assume that this will continue to work in the future.
Just a guess: When you invoke [obj autorelease] without an autorelease
pool, I would say that the object attempts to add itself to a nil
autorelease pool. If it does this with a message to this non-existent
"nil pool", nothing would happen, and the object would be a perfect
candidate for a memory leak.
I would suggest that you manually create an autorelease pool before
creating any Cocoa objects. In this way, you can clean up autoreleased
objects at any time by releasing the pool and creating a new one. At
the end of your application, you will finally be able to safely call
[NSApp terminate].
--
gue = Günther Blaschek
_______________________________________________
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