Re: Tracking object references
Re: Tracking object references
- Subject: Re: Tracking object references
- From: Greg Parker <email@hidden>
- Date: Fri, 22 Feb 2013 12:11:52 -0800
On Feb 22, 2013, at 7:42 AM, Matt Neuburg <email@hidden> wrote:
> Some specific object did send "retain". It is that specific object's responsibility eventually to send "release". That's how Cocoa memory management works. Instruments *can* know, and *should* tell me, what specific object that is. I wouldn't be here (i.e. using this aspect of Instruments) if this were not the very problem I'm having, i.e. some specific object is not fulfilling its responsibilities and I need to work out who it is. The fact that Instruments doesn't tell me this is not just some mild forgivable accident. It is Teh Suck. m.
Assume for the sake of argument that your attribution model above works. One problem is that the retaining object can hand off its responsibility to some other object, with no way for Instruments to be able to detect the change. For example, consider code that reads a value out of one strong variable, sets that variable to nil, and writes the value to a second strong variable. No retain or release calls are necessary, which means there's no way for Instruments to know that the release responsibility changed.
Another problem is that "who called retain?" is not always possible to answer. For example, the call to retain could be an optimized tail-call. In that case, the stack trace inside -retain includes no information about the caller of -retain. If you assigned blame to the caller of retain, you might be mis-attributing the release responsibility. Even worse, Instruments has no way to know whether that has happened.
In order to solve problems like these you would need some sort of debug compilation that defeats enough optimizations and preserves enough information for Instruments to see what's going on, and you'd need to compile everything (including OS libraries) this way.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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