Problems with object observing own key
-
I have an object that observes a few of it's own keys. This works
fine. The problem comes at dealloc time...
I get messages logged to the console for each of the it's own keys
that the object is observing like:
] An instance 0x1c247f50 of class GSLayerView 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 0x1c2cd520> (
<NSKeyValueObservance 0x1c270340: Observer: 0x1c247f50, Key path:
hasBackgroundColor, Options: <New: YES, Old: YES, Prior: NO> Context:
0x3281c, Property: 0x15f4df50>
...
I do remove the observers in my dealloc method, but it seems these
warnings are being fired before my dealloc method is even called.
Are there any ways to fix my code to deal with this behavior? -
On Sun, May 11, 2008 at 9:36 PM, Colin Cornaby <colin.cornaby...> wrote:
> Set a breakpoint on NSKVODeallocateBreak to stop here in the debugger.
What's does the stack trace look like from this breakpoint?
Hamish -
#0 0x94eb4993 in NSKVODeallocateBreak
#1 0x94e267c4 in NSKVODeallocate
#2 0x94d7d57f in NSPopAutoreleasePool
#3 0x945b1e54 in -[NSApplication run]
#4 0x9457f030 in NSApplicationMain
#5 0x00008208 in main at main.m:13
On May 11, 2008, at 2:08 PM, Hamish Allan wrote:
> On Sun, May 11, 2008 at 9:36 PM, Colin Cornaby
> <colin.cornaby...> wrote:
>
>> Set a breakpoint on NSKVODeallocateBreak to stop here in the
>> debugger.
>
> What's does the stack trace look like from this breakpoint?
>
> Hamish
-
On Sun, May 11, 2008 at 5:19 PM, Colin Cornaby <colin.cornaby...> wrote:
> #0 0x94eb4993 in NSKVODeallocateBreak
> #1 0x94e267c4 in NSKVODeallocate
> #2 0x94d7d57f in NSPopAutoreleasePool
> #3 0x945b1e54 in -[NSApplication run]
> #4 0x9457f030 in NSApplicationMain
> #5 0x00008208 in main at main.m:13
See stack frame #2? You should immediately have recognized that you
have a memory management issue on your hands. You're failing to
retain the object somewhere.
--Kyle Sluder -
But see, that's the thing. My objects dealloc method fires AFTER the
warning appears, so my object hasn't actually been deallocated yet.
In the deallocation my object removes the observers from itself. If my
object was actually deallocating first, I should be getting this
message.
I'll do some poking around, but I don't think this is a memory
management issue. Wouldn't be the first time I've had to eat my words
though. :p
On May 11, 2008, at 2:47 PM, Kyle Sluder wrote:
> On Sun, May 11, 2008 at 5:19 PM, Colin Cornaby
> <colin.cornaby...> wrote:
>> #0 0x94eb4993 in NSKVODeallocateBreak
>> #1 0x94e267c4 in NSKVODeallocate
>> #2 0x94d7d57f in NSPopAutoreleasePool
>> #3 0x945b1e54 in -[NSApplication run]
>> #4 0x9457f030 in NSApplicationMain
>> #5 0x00008208 in main at main.m:13
>
> See stack frame #2? You should immediately have recognized that you
> have a memory management issue on your hands. You're failing to
> retain the object somewhere.
>
> --Kyle Sluder
-
This is a general problem with KVO when observing self. As I
understand, Apple has recognised the issue though and for apps linked
or run on Leopard (one of the 2) the system should be intelligent
enough to not print warnings. The best alternative I can suggest is to
override -release so that you can sneak some kind of -willDealloc
method in before the actual de-allocation and subsequent warnings.
Mike.
On 11 May 2008, at 22:53, Colin Cornaby wrote:
> But see, that's the thing. My objects dealloc method fires AFTER the
> warning appears, so my object hasn't actually been deallocated yet.
>
> In the deallocation my object removes the observers from itself. If
> my object was actually deallocating first, I should be getting this
> message.
>
> I'll do some poking around, but I don't think this is a memory
> management issue. Wouldn't be the first time I've had to eat my
> words though. :p
>
> On May 11, 2008, at 2:47 PM, Kyle Sluder wrote:
>
>> On Sun, May 11, 2008 at 5:19 PM, Colin Cornaby
>> <colin.cornaby...> wrote:
>>> #0 0x94eb4993 in NSKVODeallocateBreak
>>> #1 0x94e267c4 in NSKVODeallocate
>>> #2 0x94d7d57f in NSPopAutoreleasePool
>>> #3 0x945b1e54 in -[NSApplication run]
>>> #4 0x9457f030 in NSApplicationMain
>>> #5 0x00008208 in main at main.m:13
>>
>> See stack frame #2? You should immediately have recognized that you
>> have a memory management issue on your hands. You're failing to
>> retain the object somewhere.
>>
>> --Kyle Sluder
-
On May 11, 2008, at 2:53 PM, Colin Cornaby wrote:
> But see, that's the thing. My objects dealloc method fires AFTER the
> warning appears, so my object hasn't actually been deallocated yet.
>
> In the deallocation my object removes the observers from itself. If
> my object was actually deallocating first, I should be getting this
> message.
>
> I'll do some poking around, but I don't think this is a memory
> management issue. Wouldn't be the first time I've had to eat my
> words though. :p
I don't think this is a memory management issue; it's come up before
on the list:
http://lists.apple.com/archives/Cocoa-dev/2006/Jul/msg00009.html
http://lists.apple.com/archives/cocoa-dev//2007/Dec/msg01217.html
Based on other posts, I don't think there's a general solution, other
than to avoid doing this sort of cleanup in -dealloc. I remove/add
observers in viewWillMoveToSuperview for NSView subclasses (which it
looks like you might have?).
hth,
Adam -
I'm seeing this warning printed in an app that's linked and run on
Leopard. Any ideas? Colin, Mike: how did you deal with it?
I have an object observing itself (through bindings) and it removes
itself as an observer inside its -dealloc method:
- (void)dealloc
{
[self unbind:@"fbItem"];
[self unbind:@"cost"];
...
[super dealloc];
}
At runtime, the NSKVODeallocateBreak warning is printed to the console
(both stderr and through syslog, so it clutters up the user's log
database):
An instance 0xcdcc30 of class MenuStructureNode 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 0x154bb9f0> (
<NSKeyValueObservance 0x1709cfb0: Observer: 0x154f66a0, Key path:
menuFbItem.fbItem, Options: <New: NO, Old: NO, Prior: NO> Context:
0x0, Property: 0x15320bb0>
<NSKeyValueObservance 0x154cc0d0: Observer: 0x154f66a0, Key path:
menuFbItem.cost, Options: <New: NO, Old: NO, Prior: NO> Context: 0x0,
Property: 0x154c0eb0>
If I move the observation-removal code to -release, so it's called
before -dealloc, the warning goes away:
- (void)release
{
if ([self retainCount] == 1) {
[self unbind:@"fbItem"];
[self unbind:@"cost"];
}
[super release];
}
Any idea how to suppress the "NSKVODeallocateBreak" warning? I really
don't like overriding -release. This object is a model object (not a
view), so there's not really a good place to clean up other than -
dealloc.
The current behavior seems incorrect -- the warning shouldn't be
printed until the object is truly deallocated (NSObject's -dealloc
method), to allow for cleanup to occur in subclasses' -dealloc
methods. Does anyone have a Radar ID I should reference to file a new
bug?
On May 11, 2008, at 6:09 PM, Mike Abdullah wrote:
> This is a general problem with KVO when observing self. As I
> understand, Apple has recognised the issue though and for apps
> linked or run on Leopard (one of the 2) the system should be
> intelligent enough to not print warnings. The best alternative I can
> suggest is to override -release so that you can sneak some kind of -
> willDealloc method in before the actual de-allocation and subsequent
> warnings.
>
> Mike.
>
> On 11 May 2008, at 22:53, Colin Cornaby wrote:
>
>> But see, that's the thing. My objects dealloc method fires AFTER
>> the warning appears, so my object hasn't actually been deallocated
>> yet.
>>
>> In the deallocation my object removes the observers from itself. If
>> my object was actually deallocating first, I should be getting this
>> message.
>>
>> I'll do some poking around, but I don't think this is a memory
>> management issue. Wouldn't be the first time I've had to eat my
>> words though. :p
>>
>> On May 11, 2008, at 2:47 PM, Kyle Sluder wrote:
>>
>>> On Sun, May 11, 2008 at 5:19 PM, Colin Cornaby <colin.cornaby...>
>>>> wrote:
>>>> #0 0x94eb4993 in NSKVODeallocateBreak
>>>> #1 0x94e267c4 in NSKVODeallocate
>>>> #2 0x94d7d57f in NSPopAutoreleasePool
>>>> #3 0x945b1e54 in -[NSApplication run]
>>>> #4 0x9457f030 in NSApplicationMain
>>>> #5 0x00008208 in main at main.m:13
>>>
>>> See stack frame #2? You should immediately have recognized that you
>>> have a memory management issue on your hands. You're failing to
>>> retain the object somewhere.
>>>
>>> --Kyle Sluder
