Cocoa mail archive
Re: Intercepting retain/release of object
FROM : Stuart Malin
DATE : Fri Mar 21 21:32:12 2008
Thanks for all the comments. I had started this thread not because I
wanted to peak under the hood, or employ non-canonical techniques,
but because I had an instance become free before its time. I had
though that intercepting -release (and also -retain, why not), would
allow me to find the place where the extra release came from. To do
that I needed to see the retain count. When I did this, I saw unusual
behavior, such as the retain count increasing then decreasing when an
instance was removed from an array. Someone on the list here pointed
out that KVO or other under-the-hood activities could lead to such
behavior, (and that it is best not to make presumptions about such
activities). I know that there are quite a few tools for observing
memory management to find leaks. In my case, I needed to find out
when a particular release was occurring. The properly implemented
intercept of -release worked for me.
On Mar 21, 2008, at 10:16 AM, Sherm Pendley wrote:
> On Fri, Mar 21, 2008 at 2:13 PM, Scott Ribe
> <<email_removed>> wrote:
> If you really want to understand what's going on, forget the
> counts, set
> breakpoints on your overloaded retain & release methods, then look
> at the
> stack trace every time. It may take a while, because there may be a
> lot
> going on behind the scenes, but it's one way to get an
> understanding. (Also
> add an override for autorelease.)
>
> I think it's worth keeping in mind that such a deep understanding
> is very, very rarely necessary to begin with. The memory management
> guidelines are actually very clear. The most common memory-
> management mistake is sprinkling memory-management code around more
> or less at random, instead of encapsulating it in easy-to-
> understand accessors. The second most common is confusing the heck
> out of one's self by looking "under the hood" in an attempt to fix
> the first kind of mistake.
>
> If you only retain and/or release in your accessors, and then
> consistently use those accessors instead of assigning directly to
> ivars, then you'll usually have no need to examine retain counts to
> debug any leaks - all you need to do is make sure the accessors are
> correct.
DATE : Fri Mar 21 21:32:12 2008
Thanks for all the comments. I had started this thread not because I
wanted to peak under the hood, or employ non-canonical techniques,
but because I had an instance become free before its time. I had
though that intercepting -release (and also -retain, why not), would
allow me to find the place where the extra release came from. To do
that I needed to see the retain count. When I did this, I saw unusual
behavior, such as the retain count increasing then decreasing when an
instance was removed from an array. Someone on the list here pointed
out that KVO or other under-the-hood activities could lead to such
behavior, (and that it is best not to make presumptions about such
activities). I know that there are quite a few tools for observing
memory management to find leaks. In my case, I needed to find out
when a particular release was occurring. The properly implemented
intercept of -release worked for me.
On Mar 21, 2008, at 10:16 AM, Sherm Pendley wrote:
> On Fri, Mar 21, 2008 at 2:13 PM, Scott Ribe
> <<email_removed>> wrote:
> If you really want to understand what's going on, forget the
> counts, set
> breakpoints on your overloaded retain & release methods, then look
> at the
> stack trace every time. It may take a while, because there may be a
> lot
> going on behind the scenes, but it's one way to get an
> understanding. (Also
> add an override for autorelease.)
>
> I think it's worth keeping in mind that such a deep understanding
> is very, very rarely necessary to begin with. The memory management
> guidelines are actually very clear. The most common memory-
> management mistake is sprinkling memory-management code around more
> or less at random, instead of encapsulating it in easy-to-
> understand accessors. The second most common is confusing the heck
> out of one's self by looking "under the hood" in an attempt to fix
> the first kind of mistake.
>
> If you only retain and/or release in your accessors, and then
> consistently use those accessors instead of assigning directly to
> ivars, then you'll usually have no need to examine retain counts to
> debug any leaks - all you need to do is make sure the accessors are
> correct.
