Re: Get error message about registered observers when Object receives dealloc message
Re: Get error message about registered observers when Object receives dealloc message
- Subject: Re: Get error message about registered observers when Object receives dealloc message
- From: Andreas Grosam <email@hidden>
- Date: Sat, 29 Aug 2009 21:26:46 +0200
On Aug 29, 2009, at 7:28 PM, Quincey Morris wrote:
On Aug 29, 2009, at 06:00, Roland King wrote:
Well first off you're not really, really doing anything wrong, that
message is in the wrong place (in my opinion), it should only come
up when the NSObject dealloc is called if things haven't been
unobserved. There's a comment in this thread about this having been
fixed, hopefully it is.
If I understand what's been said in this thread, Andreas *is* doing
something wrong. He's in good company, though, because the retain/
release mechanism has traditionally allowed many Cocoa developers to
do it wrong over the years. It's only now that the chickens are
coming home to roost.
Just to be clear, the code is running on the iPhone, hence there is no
GC. Secondly, there is no issue with release or retain. If I invoke
release from within a dealloc in order to release a certain object, I
have to do it exactly the same way - even when the current KVO issue
has been corrected somehow in my code. So, retain/release is unrelated
to the current problem. The solution to my problem seems to be to
unregister all KVO *before* the object hierarchy gets deallocated.
There are actually two things wrong here. One is that it's not
*generally* safe to manage lifetimes of mutually dependent objects
in their 'dealloc' methods.
If the dealloc method does not directly or indirectly invoke a method
of any object that is currently deallocated, the design should be
safe. But I wouldn't recommend it, because it may become a problem
later when code changes.
In this case, Andreas has said, observing objects are being released
in the observed object's 'dealloc', and the released (and therefore
deallocated) observing objects are messaging the partially torn down
observed object from their own 'dealloc'. With very careful coding,
Andreas *might* be able to make this kind of thing safe *for the
part of the object behavior that he controls*, but he can't make it
safe for the parts he doesn't control (e.g. behavior inherited from
the frameworks).
The second is that one of the behaviors he doesn't control --
unregistration of observers -- is not permitted during the 'dealloc'
of the observed object,
This is actually the piece of information that I am searching for. So,
can I take this for a fact? I'm asking because then I don't understand
the bug fixes mentioned in
http://developer.apple.com/mac/library/releasenotes/Cocoa/Foundation.html
(please see Jean-Daniels reply)
Though, I don't see why this is a *second* problem - IMHO it's just a
concrete reason of the one problem.
and must be done before that.
That's why I am proposing myself to introduce a new method -shutdown
in my classes which is responsible to tear down the dependencies from
any objects within the hierarchy -- before the root object starts to
release any object, including itself.
That's what the log message is trying to say. The bug fixes
described in the Snow Leopard release notes *don't* permit this
requirement to be ignored. [In fact, the notes explicitly say that
the consequences are memory leaks and observation info getting
attached to the wrong object.] Instead, Snow Leopard corrects the
detection of the problem in the retain/release case. That's why log
messages have suddenly started appearing. Andreas' implementation
was always wrong, but it's only being reported correctly now.
I don't know what Snow Leopard is reporting in my case - I'm running
10.5.8 and this is an iPhone application. So, there are chances that
the log that I'm getting now is still incorrect - although there
actually might be real problems.
This is not news to anyone who's been using garbage collection,
which has always had the same restriction, and enforced it. The
solution (as stated earlier in this thread) is to unregister the
observers of an observed object while it is still owned (RR:
retained; GC: referenced) by something.
Understand.
This sort of "release your resources" cleanup is sometimes much
harder to do without relying on 'dealloc', because you lose the
automatic "notification" of the end of an object's lifetime that
'dealloc' implies.
Absolutely. Even when I have a mechanism to tear down an object
hierarchy via a shutdown message, after shutdown has been received,
the object is effectively invalid. If there exists a third object that
holds a reference to this torn down object, problems may occur since
the object became invalid prematurely.
Nevertheless, it's necessary because of KVO registrations, and it's
necessary because of garbage collection.
I wish the frameworks did provide some kind of end-of-lifetime
detection that would trigger a notification before object
destruction begins. This would be something like a counterpart to
'awakeFromNib', which is a kind of beginning-of-lifetime
notification after object initialization is complete. But there
isn't anything like that in the frameworks (yet), so we have to do
it the hard way.
How could this be implemented? When an object gets deallocated it
always previously received release with retain count one or - in case
of GC - the last reference diminished. When this happens, it is
already to late for a notification.
I think, I will implement a shutdown method for any object which is
part of the object hierarchy. This method specifically tears down all
these dependancies. Of course, this message must be invoked for every
object within the hierarchy before any object receives its dealloc
message.
Thank you very much for your comments and your insights. I think it's
clear now what I have to do.
Regards
Andreas
_______________________________________________
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