Deallocation while key value observers still registered
Hi, I'm getting the message: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController 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: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. Any clues where to look? Thanks Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
what version of what operating system are you using? On 25-May-2010, at 9:14 PM, Gideon King wrote: Hi, I'm getting the message: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController 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: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. Any clues where to look? Thanks Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org This email sent to r...@rols.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
10.6.3 On 25/05/2010, at 11:17 PM, Roland King wrote: what version of what operating system are you using? On 25-May-2010, at 9:14 PM, Gideon King wrote: Hi, I'm getting the message: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController 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: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. Any clues where to look? Thanks Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
That's not it then, in Snow Leopard there was a change so that message was only emitted at the end of the dealloc() method instead of at the start which allowed you to deregister your observers in dealloc() and not get this error. In Leopard and in (I think still in) iPhone OS you get the message at the start of dealloc whether you are just about to deregister your observers or not. On 25-May-2010, at 9:33 PM, Gideon King wrote: 10.6.3 On 25/05/2010, at 11:17 PM, Roland King wrote: what version of what operating system are you using? On 25-May-2010, at 9:14 PM, Gideon King wrote: Hi, I'm getting the message: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController 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: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. Any clues where to look? Thanks Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
On Tue, May 25, 2010 at 6:14 AM, Gideon King gid...@novamind.com wrote: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController 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: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. This sounds off… you're deregistering obeservers in your observee's -dealloc? It sounds like object A has observed object B, and object B is being dealloced, which is removing its observation on object C, but the framework is complaining about object A. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
On May 25, 2010, at 10:54 AM, Kyle Sluder kyle.slu...@gmail.com wrote: This sounds off you're deregistering obeservers in your observee's -dealloc? In general this would sound off to me too, on the principle that observees normally don't know who their observers are. �It�only makes sense to me if the observee added the observers to itself in the first place, on the principle that whoever adds an observer should take it away. On May 25, 2010, at 09:49 AM, Roland King r...@rols.org wrote: That's not it then, in Snow Leopard there was a change so that message was only emitted at the end of the dealloc() method instead of at the start which allowed you to deregister your observers in dealloc() and not get this error. In Leopard and in (I think still in) iPhone OS you get the message at the start of dealloc whether you are just about to deregister your observers or not. Thanks for this -- I vaguely remember something about the change in Snow Leopard but it hadn't clearly registered in my mind. I had an idea for a perverse hack to deal with the problem in Leopard, which was to to override release and do the deregistering there if the retainCount is 1, thus sneaking in the deregistering just before dealloc but no sooner. --Andy On 25-May-2010, at 9:33 PM, Gideon King wrote: 10.6.3 On 25/05/2010, at 11:17 PM, Roland King wrote: what version of what operating system are you using? On 25-May-2010, at 9:14 PM, Gideon King wrote: Hi, I'm getting the message: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController 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: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. Any clues where to look? Thanks Gideon ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/aglee%40mac.com This email sent to ag...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
On Tue, May 25, 2010 at 9:08 AM, aglee ag...@mac.com wrote: I had an idea for a perverse hack to deal with the problem in Leopard, which was to to override release and do the deregistering there if the retainCount is 1, thus sneaking in the deregistering just before dealloc but no sooner. I believe this was actually impossible because of where the dealloc check was implemented (right at the top of -release, IIRC; -dealloc didn't actually do the checking, just the work of cleaning up). --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
Hi, I had something perhaps similar. (But have no solution, only possible further information to add). I believe that registration came in my case from InterfaceBuilder, where I had used the keyed values as entries in various textFields, using IB setup bindings in an NSPanel. (Snow Leopard). Without a solution I am just allowing the leaks by not deallocing. Would be most interested in solution. Simon On 25 May 2010, at 15:54, Kyle Sluder wrote: On Tue, May 25, 2010 at 6:14 AM, Gideon King gid...@novamind.com wrote: An instance 0x11d0ce4b0 of class NMGeneralPrintAccessoryController 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: all my observers But I have put a breakpoint on my dealloc method, and in there, I do deregister for those notifications. Dealloc is called, and I did check that it was the same object, and all the calls to deregister are there. So I don't know how it could *not* be removing the observers. This sounds off… you're deregistering obeservers in your observee's -dealloc? It sounds like object A has observed object B, and object B is being dealloced, which is removing its observation on object C, but the framework is complaining about object A. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/simon%40richstitch.com This email sent to si...@richstitch.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
I have found the problem. In awakeFromNib, I have several calls like this: [self addObserver:self forKeyPath:@thingy options:NSKeyValueObservingOptionInitial|NSKeyValueObservingOptionNew context:NULL]; And in the dealloc method, I have: [self removeObserver:self forKeyPath:@thingy]; for all the same key paths. All looked normal enough. But in the init method of the class, I was loading a nib that had my class as the file's owner, as well as being a view controller for another view. Therefore, awakeFromNib was being called twice, and although the dealloc was removing one set of registrations, the other set was being left. In my core data classes, I have all this wrapped in a boolean that avoids starting observing more than once, but I wasn't doing that in this part of my code. I found the -observationInfo method useful in tracking this down - I knew there must be some method like this, but had not found it before. Thanks for the suggestions etc. Gideon On 26/05/2010, at 2:29 AM, Kyle Sluder wrote: On Tue, May 25, 2010 at 9:08 AM, aglee ag...@mac.com wrote: I had an idea for a perverse hack to deal with the problem in Leopard, which was to to override release and do the deregistering there if the retainCount is 1, thus sneaking in the deregistering just before dealloc but no sooner. I believe this was actually impossible because of where the dealloc check was implemented (right at the top of -release, IIRC; -dealloc didn't actually do the checking, just the work of cleaning up). --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
On Wed, 26 May 2010 03:08:31 +1000, Gideon King said: I have found the problem. In awakeFromNib, I have several calls like this: [self addObserver:self forKeyPath:@thingy options:NSKeyValueObservingOptionInitial|NSKeyValueObservingOptionNew context:NULL]; And in the dealloc method, I have: [self removeObserver:self forKeyPath:@thingy]; for all the same key paths. All looked normal enough. But in the init method of the class, I was loading a nib that had my class as the file's owner, as well as being a view controller for another view. Therefore, awakeFromNib was being called twice, and although the dealloc was removing one set of registrations, the other set was being left. In my core data classes, I have all this wrapped in a boolean that avoids starting observing more than once, but I wasn't doing that in this part of my code. I found the -observationInfo method useful in tracking this down - I knew there must be some method like this, but had not found it before. Thanks for the suggestions etc. Glad you've tracked it down. Just a comment though: my understanding is that calling removeObserver from dealloc is, in general, discouraged. See here for some reasoning: http://www.karppinen.fi/analysistool/ -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Deallocation while key value observers still registered
Sean McBride wrote: On Wed, 26 May 2010 03:08:31 +1000, Gideon King said: Glad you've tracked it down. Just a comment though: my understanding is that calling removeObserver from dealloc is, in general, discouraged. See here for some reasoning: http://www.karppinen.fi/analysistool/ I don't believe that's actually true - although it's often stated as fact. There's nothing in any apple documentation I've ever seen which discourages it, if you run under GC it will even do this for you when your objects are cleaned up. There's a long thread on this about a year ago where we were discussing the change in Snow Leopard to move the warning to the end of the dealloc method. The only reason for doing that would be to allow you to remove observers and the wording of the release note is quite persuasive. I do this, quite often, I've never had an issue with it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
