Re: Debugging memory leak in NSURLSession with ARC
Re: Debugging memory leak in NSURLSession with ARC
- Subject: Re: Debugging memory leak in NSURLSession with ARC
- From: Joar Wingfors <email@hidden>
- Date: Thu, 01 Jan 2015 18:50:43 -0800
> On 1 jan 2015, at 18:26, Graham Cox <email@hidden> wrote:
>
>
>> On 2 Jan 2015, at 12:48 pm, Quincey Morris <email@hidden> wrote:
>>
>> **** That usually means the block and the ‘self’ it captured mutually refer to each other. I’m betting this is what’s wrong in your case.
>>
>>
>
>
> Quincey, thanks for your lengthy and well-thought-out reply (as usual) :)
>
> I think you've hit the nail straight on the head (as usual), with the block/self problem. It's one I knew about before, but had forgotten again in my excitement at getting the code running. The question is what to do about it.
>
> My handler block refers to 'self' quite extensively - it calls other methods of self and also refers to properties such as self.delegate. I'm not quite sure how I can rework it not to refer to self. Maybe I just need to not use the completion block approach and use a delegate callback instead. I need to go away and think about this... thanks for the slap about the head.
You can always employ the weakself+strongself pattern:
__weak Foo *weakSelf = self;
AsyncBar(^{
Foo *strongSelf = weakSelf;
if (nil != strongSelf) {
[strongSelf doStuff];
// more stuff
}
});
That said, if an object is going away it's typically better to use explicit cleanup / teardown, than relying on __weak. Tear down bindings, KVO, timers, delayed runloop invocations, outstanding async work, etc. More direct, more predictable, easier to troubleshoot/debug.
Joar
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden