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: Roland King <email@hidden>
- Date: Fri, 02 Jan 2015 11:01:08 +0800
> On 2 Jan 2015, at 10:52, Joar Wingfors <email@hidden> wrote:
>
>
>> On 1 jan 2015, at 18:22, Roland King <email@hidden> wrote:
>>
>> +1 for all of this. I wouldn't call leaks an utter waste of time, but it really does only find pure retain cycles (which it then annotates very nicely) and not memory which is really is pinned by a real reference which is more often the case. Also, if you're using KVO anywhere, this tends to entirely defeat leaks even though KVO isn't a strong reference and shouldn't be treated like one, it is. That makes leaks less useful than it could be for me because I'm always KVO'ing something.
>
>
> I don't think leaks would find cycles. I could be wrong, but I don't think it's sophisticated enough to perform that additional level of analysis. I think it only finds stuff that's truly referenced from nowhere else on the heap.
>
Perhaps we're talking cross purposes because it definitely finds what I'm calling cycles, where object A references B strongly and B references A strongly (or a longer chain of objects which eventually forms an equivalent loop). If that loop of objects isn't strongly referenced by anything else and is thus 'leaked', leaks not only finds it but gives you a pretty diagram showing how all the objects are strongly referencing each other, with property names etc.
IIRC that facility arrived the same year as ARC. It's occasionally useful.
_______________________________________________
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