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 11:25:26 -0800
On 11/29/06, Stefan Werner <email@hidden> wrote:
On Nov 29, 2006, at 7:34 PM, Shawn Erickson wrote:
> It doesn't even work as long as their is a single instance since
> autorelease pools are per thread (uses thread local storage).
So I tried that that too, no dice.
I created one NSAutorelasePool per thread, released it when the
thread quit - still leaking.
How long do these threads exists? How many objects get created while
the thread exits?
Review...
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/AutoreleasePools.html#//apple_ref/doc/uid/20000047-1041876-CJBFEIEG>
> 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.
ObjectAlloc shows me that the NSTask instance is the leak, so the
other stuff appears to be behaving correctly.
Is your C++ destructor getting called?
> 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
That was actually my initial approach, I created an autorelease pool
in the first line of every C++ method and releasing in right before
it returns. Was leaking just the same.
Then likely autoreleased items aren't your issue but you should still
be doing this.
> 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).
Which actually is. The first thing that my C++ class creates is an
AutoreleasePool, very last thing it does is releasing that pool,
which pretty much assures that during the lifetime of that object, a
pool is in place as long as all the function calls to that object
come from the same thread (which they do).
Again autorelease pools are per thread and maintained in a stack, they
shouldn't be associated with an instance of an object. If other code
called by that thread allocates or releases autoreleeas pools the
stack of pools could easily break the assumption you outlined
above.... invalidating the autorelease pool you associated with the
object.
If, at any point, there would not be an AutoreleasePool where one is
required, I should see a message about this in the console, right?
Correct. Of course just because you have an autorelease pool in place
doesn't mean that that autorelease pool is getting drained in a
sensible fashion.
-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