Re: ARC, Instruments and retain cycles
Re: ARC, Instruments and retain cycles
- Subject: Re: ARC, Instruments and retain cycles
- From: Roland King <email@hidden>
- Date: Sat, 24 Dec 2011 11:00:00 +0800
Didn't totally understand all of that .. XCode 4 is released and the leaks and cycles detection stuff is part of it, you can find the Cycles and Roots tab on the screen, although I was unable to get it to show a cycle in my app, which had one, and indeed writing a simple app which makes two objects and sets them up with a retain cycle triggers it, and you get a really nice diagram showing you what you did with pretty arrows showing where the retain cycle is. Documentation does seem to be lagging however, but that seems to be true of a lot of Instruments, the documentation is behind the implementation.
So .. having proved there is cycle detection and it works in a simple example I was trying to figure out why it didn't detect it in mine. The cycle was short, 3 objects in the end, with strong 1-2-3-1 references. The only way that would not be seen as a retain cycle is if there was still another pointer from outside the cycle into one of the 3 objects in it. But I knew I had no pointers to these objects (they're view controllers) and I thought cycling through a number of times would remove any object pointers from stack or other memory. I wanted to report it as a bug but couldn't come up with a way to reproduce.
Finally I realized this morning that not only were the objects in a retain cycle, one of them was KVO observing another. Of course by default all KVO is registered in a global table keyed by the observed object, that was where leaks was able to find a path to one of the objects in the cycle from the root and thus not see it as a cycle. I now have a nice test-case which shows that. I'm going to report that as a bug as in this case there's no way a Key Value observation could ever be generated and only the implementation of KVO is causing leaks not to find a cycle. Similarly, I'll suggest that if a cycle is only reachable via a weak pointer, that too should show up as a leak, or a potential one, as that mirrors what garbage collection would do, objects not strongly reachable would be collected, so cycles only weakly reachable should show up as leaks.
On Dec 23, 2011, at 11:26 PM, Fritz Anderson wrote:
> On 22 Dec 2011, at 10:58 PM, Roland King wrote:
>
>> Clearly that's from a number of months ago whilst this stuff was under NDA, I would think that is no longer the case.
>>
>> Does anyone know anything about improved leak detection in instruments especially as it pertains to retain cycles? This one was a classic retain cycle, even though it comprised a number of objects the fact there was one retain holding it all up should have made it very detectable by a leak detector. I ran the app for some time and cycled around to give some time for old memory to be overwritten etc. but it never found any of them, which is rather disappointing.
>
> A priori, a company might put a pre-release product under NDA because
>
> - it wants to preserve the product's competitive advantage.
>
> - it wants to prevent people's deferring purchases till the new product comes out.
>
> These, as you suggest, become moot when the product is released. These, however, never become moot, and the company might never release the NDA for them:
>
> - it doesn't want publicity for the quality of unfinished features. ("The Frobber pre-alpha sux! I'm never going to buy it!") (Closer to home, a lot of the hatred for Xcode 4 derived from what it was like in prerelease. I didn't bother even starting "Xcode 4 Unleashed" until Xcode 4 was released.)
>
> - it doesn't want disappointment over features that don't make it to release, which turns the story from what's new to what's lacking. ("Frobber XVI FAIL! The prototype had Death Lasers!")
>
> - it doesn't want "documentation" of unpublished features to confuse users of the published version. ("The Frobbing Life web site tells me to push the 'Frob Fiercely' button, but it isn't there / reformats my Frobber.")
>
> — F
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden