Re: Tracking object references
Re: Tracking object references
- Subject: Re: Tracking object references
- From: Matt Neuburg <email@hidden>
- Date: Fri, 22 Feb 2013 07:42:47 -0800
On Sun, 17 Feb 2013 12:16:47 -0600, Ken Thomases <email@hidden> said:
>On Feb 17, 2013, at 11:50 AM, Matt Neuburg wrote:
>
>> On Sat, 12 Jan 2013 11:13:13 +0000, Mike Abdullah <email@hidden> said:
>>>
>>> The allocations instrument can show you all presently allocated objects. Find the object(s) you're interested in from that list and you can view its history of being retained and (auto)released, to figure out what is still holding onto it.
>>
>> Actually, Instruments is no help in figuring out "what is still holding onto it". That's not entirely unreasonable, since in a very real sense *no* object is "holding onto" anything; there are only messages and the object's own internal retain count.
>
>Well, you can't figure out what object is holding onto another object, but you can figure out which _body of code_ is holding onto an object.
>
>> But it sure would be nice if Instruments did give more info about this, so that one could try to track down which retains are balanced by which releases (and which retains, therefore, are unbalanced).
>
>Well, Instruments can no more divine which release balances which retain as it can know what object might "hold" what other object.
The words "which body of code is holding onto an object" don't have any meaning to me, and I don't think they have any meaning to you either. You're just waving your hands. If I wanted to wave my hands I wouldn't be using Instruments.
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.
--
matt neuburg, phd = email@hidden, <http://www.apeth.net/matt/>
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
_______________________________________________
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