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: Roland King <email@hidden>
- Date: Sun, 30 Aug 2009 11:43:48 +0800
On Aug 30, 2009, at 1:28 AM, Quincey Morris wrote:
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, and must be done before that. 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.
Here are the release notes on this by the way. I note they only talk
about running in non-GC mode. However in both cases mentioned an
object has unregistered as an observer of an observed object during
the dealloc of that observed object and these release notes say that
is ok. In the first case the object is itself, in the second case it's
an object retained by the observed object who's release by the
observed object during dealloc() caused it also to be dealloc()ed and
during that deallocation it unregistered itself as an observer of the
observed object. That's actually exactly what the thread starter is
doing and the release notes say 'correctly unregistered' which
strongly indicates that it's perfectly allowable for unregistration of
observers to happen during dealloc of the observed object and that the
message he's been getting is a false positive.
I still agree that relying on nothing else having retained the child
object such that its dealloc is guaranteed to be called when you
yourself release it is bad and that an explicit request to observing
objects is much safer, and that it wouldn't work in GC mode where your
child object could be cleaned up .. I have no idea when. However
unless there's another note I've not seen, from this particular note I
take it that it is allowable for registrations on you to be removed
during your dealloc().
One way to trigger that could be to have a 'canBeObserved' property
which your children are all observing, flip that to NO at the start of
dealloc() which would tell them to remove all their observations and
then proceed from there. That assumes you're allowed to unregister
observations during an observation callback.
... release note follows ...
Bug Fixes in Debugging of Objects Being Deallocated With Observers
Still Registered When Not Running Garbage-Collected (Updated since
March 2009 Seed)
In Mac OS 10.3 through 10.5 there was a bug in which a valuable
debugging feature of KVO was not triggered when an object observing
itself did not remove itself as an observer of itself during
deallocation. This bug has been fixed in Mac OS 10.6. When this
happens Foundation now logs something like "An instance 0x100771010 of
class MySelfObservingClass was deallocated while key value observers
were still registered with it. Observation info was leaked, and may
even become mistakenly attached to some other object. Set a breakpoint
on NSKVODeallocateBreak to stop here in the debugger. Here's the
current observation info:…"
There was another bug in which this logging was done spuriously when
an object observed by a second object was deallocated, its
deallocation caused the release of the second object, and the second
object correctly unregistered itself as an observer of the first
object at that time due to its own deallocation. This bug has also has
been fixed in Mac OS 10.6.
To summarize, KVO's test for objects being deallocated with observers
still registered exhibited both false negatives and false positives,
and both kinds of mistake have been fixed.
_______________________________________________
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