On May 20, 2011, at 5:48 AM, Ben wrote:
> MyImportController *controller = nil;
> CleanupBlock cleanup = ^{
> [controller release];
> // Other stuff
> };
> controller = [[MyImportController alloc] initWithCleanupBlock:[[cleanup copy]
> autorelease]];
> [controller start];
> // The controller calls cleanup() when it's done
>
>
> It doesn't exhibit any problems that I can see, but the static analyzer
> complains that I'm leaking the controller object in the second example. Am I
> actually doing something wrong here? If not, is there a way to make analyzer
> recognise this?
Ben,
The static analyzer is correct. The block captures the variable "controller" at
the time of the block's creation, which in this case is nil, and sending
messages to nil objects are for better and for worse allowed by the language.
One could naively and wrongly "fix" this by decoupling the init method:
controller = [[MyImportController alloc] init];
// "controller" is now non-nil and safe to capture
[controller setCleanupBlock: ^{ [controller release] }];
[controller start];
But because blocks automatically retain/release captured objects, the above
code has actually just created a simple retain cycle and will never be freed
(the controller retains the block and vice versa).
In general, objects should not be responsible for their own cleanup. One might
frequently get away with that in single-threaded code, but in concurrent code,
that pattern is much more risky. Also, some of the memory analysis tools like
"leaks" will get confused if a given object is the only reference to itself and
will report these objects as leaks.
There are other problems with this pattern too. If the controller has any
accidental or intentional residual uses of itself after the cleanup handler
runs, then things will blow up (a "use-after-free" bug).
It would be hard at this point to give some good general advice without knowing
more about what your design goals are.
Good luck!
davez_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
