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:52:54 -0800
> 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.
> There's an old blog by bbum which covered using generational analysis for finding leaks which aren't leaks. Xcode has changed quite a lot since then but some of the screens look quite similar even now. I routinely put my code through this torture test, it's so easy to run and the results are often very illuminating.
>
> http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/<http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/>
That functionality has since been integrated into Instruments, so it's easier to use.
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