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.
