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: Fri, 28 Aug 2009 23:32:55 +0800
I think this is one of those unfortunate messages which comes out
before the dealloc method even runs, just entering the dealloc method
with registered observers logs it. It's possible it would be better if
it was only logged at the point say NSObject dealloc was called, but
it's not, it's called at the start of your own dealloc.
That either indicates it's a bug in the message because it doesn't
allow for the case where a dealloc method unregisters the things
observing it .. or perhaps you're not really supposed to be doing it
there. Normally an object will register its interest in observing
another object and the same object will then unregister later. It's a
little unusual for an object to unhook the objects which are observing
it. Actually how are you even doing that, do you have a list of all
the objects and paths which are observing you?
I can sort of see how this might happen in practice, you create an
object who's lifetime is determined by external factors, but observers
hook up to it without retaining it and .. do something with
observations of the key properties. Eventually the object gets
released because all the other things which cared about it release it
and you want to remove the observations and dealloc is the natural
place to do that.
I'd try to get it the other way around myself if possible, have the
observer retain the object observed and register the observation, then
have it drop the observation at a later point and release the object,
which then eventually deallocs. I sort of understand how that could be
hard if your object lifecycle is complicated and you were trying to
use the implicit reference count to manage object lifetime and have
the observers not retain and have a sort of weak reference.
Is there something other than dealloc you can use to denote when
everything except observers have finished with your object so you can
set an observed property which basically says "I'm useless and want to
die" and causes any observers to remove the observation and release
the object, which will then dealloc?
On Aug 28, 2009, at 9:56 PM, Andreas Grosam wrote:
I'm using key-value-observing where an instance of class MyObservee
has been registered for KVO with other objects which observe a value
in a key path (e.g.: @"drives.model.port"):
The observee itself unregisters all observers in its dealloc method:
@implementation MyObservee
- (void) dealloc
{
[self removeAllObservers]; // basicly: [self
removeObserver:observer forKeyPath:key];
[super dealloc];
}
The observers are sill alive when the observee receives its dealloc
message.
When the observed instance receives its dealloc message, I'm getting
this error message in the console, before the first line of code in
the dealloc method will be executed (note: BEFORE [super deallocate]
has been invoked):
2009-08-28 14:57:49.753 MyApp[886:20b] An instance 0xd21b60 of class
MyObservee is being deallocated while key value observers are still
registered with it. Observation info is being 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:
<NSKeyValueObservationInfo 0xd38e00> (
<NSKeyValueObservance 0xd39880: Observer: 0xd356e0, Key path:
drives.model.port, Options: <New: NO, Old: NO, Prior: NO> Context:
0x16df0, Property: 0xd38990>
...
The class MyObservee does NOT have a sub class - that is, [super
dealloc] will not be called somewhere prematurely.
The base class of MyObservee is NSObject.
Am I doing something wrong here?
Thanks in advance for hints.
Regards
Andreas Grosam
_______________________________________________
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