Re: NSWindowController retain counts, chapter 2
Re: NSWindowController retain counts, chapter 2
- Subject: Re: NSWindowController retain counts, chapter 2
- From: "Shawn Erickson" <email@hidden>
- Date: Tue, 7 Oct 2008 11:21:37 -0700
On Tue, Oct 7, 2008 at 11:05 AM, James Walker <email@hidden> wrote:
> I think the important thing is that the window was not getting deallocated.
> After more experimentation, this seems to be another symptom of the same
> basic problem as in my previous NSWindowController thread, which is that a
> Carbon app using WaitNextEvent still needs to set up and release its own
> autorelease pools each time through the event loop. When I do that, the
> problem goes away. And unlike my previous workarounds, this doesn't make me
> feel like I'm doing voodoo.
Have you looked at the console log or run log if running from Xcode
for messages like the following?
*** _NSAutoreleaseNoPool(): Object <SomeObjectPointer> of class
<SomeClassName> autoreleased with no pool in place - just leaking
Of course you may not be seeing those if you have a top level
auto-release pool setup, say in your main entry point, that simply
exists for the life of the application. If you do have such a top
level auto-release pool that exists for the life of the application
consider knocking it out (at least temporarily) to help you detect
code pathways that are using Cocoa API yet they are not correctly
managing an auto-release pool.
Note the event loop in a NSApplication based application with do such
management for you, at least on the main thread (aka which is running
the even loop, aka main runloop).
(of course I do wonder why you are still using Carbon event
management, it really is time to be switching off of that)
-Shawn
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden