Re: Re: NSTask memory leak
Re: Re: NSTask memory leak
- Subject: Re: Re: NSTask memory leak
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 29 Nov 2006 10:34:36 -0800
On 11/29/06, Stefan Werner <email@hidden> wrote:
On Nov 29, 2006, at 6:19 PM, Shawn Erickson wrote:
> What you should do is ensure an autorelease pool is in place during
> any method call that sends objective-c messages and released on exit
> from such methods (note the that in a Cocoa application an autorelease
> pool is managed for you on the main thread).
Well, I did try different patterns of creating/destroying the
autoreleasepools with no success so far, including creating/
destroying one per thread. Making it a member of the C++ class seemed
like the most convenient way, but I see now that this only works as
long as only one instance of that class exists at a time (which
actually is true in my case).
It doesn't even work as long as their is a single instance since
autorelease pools are per thread (uses thread local storage).
> Any NSObject subclass
> that you need to exist for the life of your C++ class must have either
> an implicit retain (alloc, copy, etc.) or explicit retain on the
> object. Then on destruction of the C++ is must balance that retain
> with a release (or autorelease).
Given that my NSTask is created through alloc/init an later released
explicitly and all the other Cocoa objects in my C++ class are
autoreleased implicitly, I should be fine here, right?
Your management of the NSTask instance looks correct but I cannot
comment on the other Cocoa objects created directly or indirectly by
your C++ class since we don't know if an autorelease pools exists at
the time the C++ method is called or how such an autorelease pool is
being managed.
Ideally each of your C++ methods (not just the constructor) should
create an autorelease pool before sending any messages and release
that pool before returning from the C++ method unless you know that
100% of the time the thread calling the C++ method will have a
autorelease pool in place (that gets drained in a sensible fashion
while the application is executing).
I suggest you fire up ObjectAlloc and have it track CF & ObjC
reference counting and backtraces. Then under the instance browser
locate the object you believe to be leaking. This should then list
events for the object and double-clicking on those events should list
a call stack. Also look in the console log for messages about objects
leaking because of not having an autorelease pool in place.
-Shawn
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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