Re: ARC Retain Cycles
Re: ARC Retain Cycles
- Subject: Re: ARC Retain Cycles
- From: Roland King <email@hidden>
- Date: Mon, 21 Apr 2014 06:40:30 +0800
On 21 Apr, 2014, at 3:51 am, Jens Alfke <email@hidden> wrote:
>
> On Apr 20, 2014, at 11:58 AM, Cody Garvin <email@hidden> wrote:
>
>> Second, while using instruments use the “mark heap” tool. Get your app up and running. Mark the heap. Then start your image downloads, while that is transpiring, mark the heap again. This will help narrow down the code that could possibly be causing this.
>
> +1. Instruments has some great tools for this. I’m still learning my way around, but last time I was debugging a memory leak, I somehow got Instruments to show a graphical representation of the reference cycle. It literally drew me a f*ing diagram of where my bug was. Very impressive.
>
>
Yes - that's the 'Leaks' tool, it even has its own icon in the choice box at the start. You run with it, when a leak shows up there's a spike in the line and you can go find the leak and get the diagram of the cycle, very useful. Showed that at WWDC 2 or even 3 years back.
I have found it suffers from one annoying flaw. I believe I have this correct, haven't looked for a while. If A and B are in a cycle and there are no strong references to them from elsewhere in the code (there can be weak ones) it will find the cycle and show it. If however one of A or B happens to be KVO'ing the other, which happens a lot in my code, I use KVO everywhere, Leaks doesn't find the cycle. That's wrong, KVO doesn't make a strong reference, as you can tell from the 'freed when KVO was still attached to it' message, however it trips up Leaks. My handwaving belief is that KVO information is kept in a separate table somewhere and the Leaks process sees the A or B pointer in that memory and conservatively assumes the objects are referenced. I should probably file a but one day.
It's worth running anyway, as is the old bbum heap generations trick or just looking at persistently growing object allocations. I've found most of my leaks that way.
_______________________________________________
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