By referencing instance variables within the block, you're causing the block to 
retain self, and since self retains (copy'd) the block, you've got a retain 
cycle.

The easiest way to fix this is to break the retain cycle yourself.  Doing 
"[self setCompletionBlock:nil];" at the end of the block should be adequate.

Dave

On Sep 30, 2010, at 9:17 AM, Andreas Grosam wrote:

> I've subclassed a NSOperation and declared a completion block in the 
> initializer as follows:
> 
> - (id) initWithParameter:(id)parameter
> {
>   self = [super init];
>   if (self != nil) {
>       [self setCompletionBlock:^{
>           NSLog(@"operation completed"); 
>           [someIvar release], someIvar = nil;
>       }];
> 
>       // ... initialize ivars
>   }
>   return self;
> }
> 
> 
> The problem is now, once a completion block has been defined and set as shown 
> above, the NSOperation instance will never be dealloced. I noticed, when 
> -setCompletionBlock: returns, the retain count of the NSOperation instance 
> has been incremented by one. 
> 
> When there is no completion block set, the NSOperation object will be 
> deallocated as expected some time later when the operation finished.
> 
> The -initWithParameter: method is invoked on the main thread.
> 
> The code of the completion block is trivial: It logs to the console and 
> simply releases certain ivars. So, there should no autoreleased object 
> (namely the operation object itself) left in some unknown execution context 
> possibly without a pool and hence leaking.
> 
> 
> As a side note: according the docs, the exact execution context for the 
> completion block is undefined. So, I think this means, we should better use 
> synchronization primitives when accessing ivars since the dealloc method 
> might still executing, right?
> 
> 
> This is running on iOS.
> 
> 
> Any hints?
> 
> 
> 
> Thanks in advance
> Andreas
> _______________________________________________
> 
> 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/davedelong%40me.com
> 
> This email sent to davedel...@me.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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

Reply via email to