Re: NSTask memory leak
Re: NSTask memory leak
- Subject: Re: NSTask memory leak
- From: "Shawn Erickson" <email@hidden>
- Date: Wed, 29 Nov 2006 09:19:50 -0800
On 11/29/06, Stefan Werner <email@hidden> wrote:
Hi,
I'm facing a situation where my NSTask doesn't seem to release its
memory, even though I'm properly releasing it and the AutoreleasePool
around it. I am using it from a Carbon app, does that maybe make a
difference?
Appended is how I wrapped NSTask in a C++ class (it's an abstraction
class for platform independence). When I run my code using this class
in ObjectAlloc, it tells me that NSTask and its copy of the arguments
array are leaking.
I would guess that I'm doing something wrong with the AutoreleasePool?
BProcessCocoa::BProcessCocoa(const BPath& iExecutable, const int
argc, const char* argv[])
{
NSApplicationLoad();
mPool = [[NSAutoreleasePool alloc] init];
mTask = [[NSTask alloc] init];
[mTask setLaunchPath:[NSString
stringWithUTF8String:iExecutable.GetFullPath()]];
NSMutableArray* array = [NSMutableArray arrayWithCapacity:argc];
for (int i = 0; i < argc; i++)
{
[array addObject:[NSString stringWithUTF8String:*argv]];
argv++;
}
[mTask setArguments:array];
[mTask launch];
}
BProcessCocoa::~BProcessCocoa()
{
[mTask waitUntilExit];
[mTask release];
[mPool release];
}
This is a broken pattern for autorelease pools. Autorelease pools are
maintained in a stack (per thread) so when you create an autorelease
pool it is pushed onto the stack of pools. When an autorelease pool is
drained (dealloc) it will drain all autorelease pools above it on the
stack.
Review...
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/AutoreleasePools.html#//apple_ref/doc/uid/20000047-997594-EGGBFFED>
In other words autorelease pools should never be an instance
variable... they thread related.
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). 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).
-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