Re: Tracking object references
Re: Tracking object references
- Subject: Re: Tracking object references
- From: Jean Suisse <email@hidden>
- Date: Fri, 22 Feb 2013 23:43:47 +0100
I am not taking any sides here, but rather just interested in the topic at hand : Tracking object references.
I had met an issue once that I never solved, which did require me to track down retain / release calls. What I did was to find in my code every explicit or implicit (@property accessors) calls to retain or release for the leaked instance and insert there a log statement with the value of self and a message telling me if retain or release was called. Then a few lines of php code (regular expressions weren't available in cocoa at that time) were able to remove all the balanced retain/release. That should have revealed which instance was responsible for the trouble.
This didn't help me much because the source of the leak wasn't in my code (turns out the leaked objects were actually copies made by NSTableView), but maybe it can help you.
Jean
On 22 févr. 2013, at 21:11, Greg Parker wrote:
> 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