Re: Stacks & Memory Management.
Re: Stacks & Memory Management.
- Subject: Re: Stacks & Memory Management.
- From: Robert Marini <email@hidden>
- Date: Sun, 21 Dec 2008 13:13:55 -0500
Overriding retain/release for the purpose of setting a breakpoint
shouldn't ever require touching retaincount. When I first started to
play with cocoa a few years ago I recall attempting to use it to debug
a retain cycle, it wasn't of any use and drove me mad(der) for a few
minutes.
Sent from my iPhone
On Dec 21, 2008, at 1:05 PM, Scott Ribe <email@hidden>
wrote:
Do not look at the retain counts. Down that path lies madness.
Frankly, -retainCount should be removed (or, better, modified to just
return rand()).
I wonder if the documentation should be updated with an explicit
warning:
---
Because any number of framework objects may have retained an object
in order
to hold references to it, while at the same time any number of
autorelease
pools may be holding any number of deferred releases on an object,
it is
very unlikely that you can get useful information from retainCount.
If you
think you can look at the value of retainCount in order to help
debug a
memory problem, then you probably do not understand Cocoa memory
management
well enough to debug the problem and will only confuse yourself
further--in
that case you should review
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Memory
Mgmt.html> and/or ask for help on the cocoa-dev mailing list.
---
Now I phrase things very carefully in that, because I have in the
past found
it helpful to override retain, release, & autorelase in order to set
breakpoints and see all the memory management actions on an object. In
theory one should not have to do that. In theory one should just
understand
and follow the rules. But I had a weird failure to follow the rules
which I
was having trouble locating. (And of course, there is the very
occasional
framework bug as well.) So it's not altogether true that one should
never
snoop into retain/release, just that watching retainCount is a nearly
completely useless way to do it.
--
Scott Ribe
email@hidden
http://www.killerbytes.com/
(303) 722-0567 voice
_______________________________________________
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
_______________________________________________
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