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: Quincey Morris <email@hidden>
- Date: Sat, 29 Aug 2009 22:12:00 -0700
On Aug 29, 2009, at 20:43, Roland King wrote:
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.
Yes, that what it seems to say, and that's a pretty big mystery.
Here's what we have:
a. When there *is* an error message, it says, "An instance of ... was
deallocated while key value observers were still registered with it."
That implies pretty strongly that there is something you're not
supposed to do.
b. The release notes say that it was wrong for this message to appear
"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". So this sort of
thing should be OK.
c. The release notes also talk about "KVO's test for objects being
deallocated with observers", which implies that it isn't OK for
objects to be deallocated with observers. That seems to contradict b,
which in turn seems to contradict a.
d. It's possible that "deallocation" means the end of the deallocation
process (i.e. when the NSObject implementation does whatever it does),
rather than the beginning of the deallocation process (i.e. when the
most derived dealloc override is first invoked). If that were true,
then a-c wouldn't really contradict each other.
e. It's possible that the rules for RR are laxer than the rules for
GC, because (as you pointed out) the scenario in b does seem to remove
the observations deterministically, whereas in the equivalent GC case
that determinism doesn't exist.
f. I don't know when the isa-unswizzling occurs either, so I'm not
sure how or if that plays into all of this.
g. Andreas has reported that the error message occurs at the
*beginning* of the deallocation process. If that's a frameworks bug,
that would mean that Snow Leopard, instead of fixing bugs in dealloc-
time KVO-registration error reporting, *introduced* bugs in error
reporting. That's possible, but (if true) ironic and puzzling.
h. It's possible that Andreas is getting the error message not because
of the indirectly-deallocated observers he told us about, but because
of some *other* observer that's not being removed at all. (That
doesn't make any sense in terms of the timing of the error message,
but oh well.)
Pretty much, that's 8 ways of saying "I dunno." Did I leave anything
out? :)
_______________________________________________
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