Re: NSTask memory leak
Re: NSTask memory leak
- Subject: Re: NSTask memory leak
- From: Stefan Werner <email@hidden>
- Date: Wed, 29 Nov 2006 20:15:10 +0100
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.
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.
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.
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).
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?
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.
This is how I got here. ObjectAlloc clearly points out that this one
NSTask (to be precise, a NSConcreteTask) and its copy of the argument
array are leaking (my initial instance of the arguments array appears
to be deleted from memory correctly).
Also look in the console log for messages about objects
leaking because of not having an autorelease pool in place.
I didn't see any messsages whatsoever. That's why at first I assumed
everything was OK, since I remember seeing these messages in some
other Cocoa apps I worked on.
Stefan
_______________________________________________
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