Thanks Jack and Shem for your counsel. For neary all of my code, I
have nice, straightforward retain-release pathways. The one that had
been giving me trouble is an oddball: I have a factory class that
generates an instance. That instance is bounced around handlers of a
state machine. Most of the state transitions are asynchronous, and
the object is passed via performSelector: across cycles of the run
loop. Without the bug, the terminus of the instance is clear, and the
object is released (and hence deallocated). It wasn't the _logic_
that was messing me up, but a bug -- an erroneous and improper
release. All I had wanted to do (with regard to my original post)
was find the place of that extra (and quite improper) release.
Overloading -release did lead me to the culprit -- a destructor in an
ancillary object that had a member which held a reference to the too-
many-times released object -- all I had needed to do was set that
member to nil (something unnecessary that I tend to do for
"cleanliness" of memory) but had mistakenly released the value held
by that member. Yes, a bug. A simple mistake. FINDING such a bug
wasn't easy because all the normal aspects of the trouble-plagued
object's retain and release was fine. Which was why I decided to
intervene -release and find out what was calling it the "extra" time.
Aside from curiosities encountered while doing so, the approach led
me swiftly to the culpable cause.
On Mar 23, 2008, at 6:31 PM, Jack Repenning wrote:
On Mar 21, 2008, at 2:36 PM, Sherm Pendley wrote:
In short, the fact that you need a means to track down your -
retain and
-release calls is indicative of a deeper problem. Examining the
retain count
will not only fail to solve that problem, but will also obfuscate
the issue
even further. You'd be far better off asking yourself why your -
retains and
-releases are so scattered that they're difficult to find and
verify in the
first place - that's the *real* problem, not whatever arbitrary
value you
happen to get back from -retainCount.
There are really two bits of advice, here, and they're separable.
The first is: you'll never make any sense out of retainCount.
Might as well just take that one to the bank. Forget retainCount.
There's way too much stuff going on that you can't see in the code,
you'll never make sense of it all. That's the easy part.
The second is: it's best form to handle your retain/release stuff
in the simplest, most on-sight verifiable way you possibly can. If
you find yourself wondering where an extra or missing retain or
release is, then your best conclusion is that your retain/release
code is too confusing. Doing it in the accessors is the simplest,
most at-a-glance policy, and it covers most use. In fact, Obj-C
2.0 provides you with a handy short hand to do it exactly this way,
@property(retain). Breaking in reatain and release (and maybe
autorelease) can tell you things that make sense (unlike
retainCount), but if you have to do that, your code's too
complicated -- you'll have to do it again and again, every time you
make changes. Save yourself the trouble. Simplify.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
