• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Get error message about registered observers when Object receives dealloc message
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 10:35:49 +0800


On Aug 30, 2009, at 1:28 AM, Quincey Morris wrote:

On Aug 29, 2009, at 06:00, Roland King wrote:

If I understand what's been said in this thread, Andreas *is* doing something wrong. He's in good company, though, because the retain/ release mechanism has traditionally allowed many Cocoa developers to do it wrong over the years. It's only now that the chickens are coming home to roost.

There are actually two things wrong here. One is that it's not *generally* safe to manage lifetimes of mutually dependent objects in their 'dealloc' methods. In this case, Andreas has said, observing objects are being released in the observed object's 'dealloc', and the released (and therefore deallocated) observing objects are messaging the partially torn down observed object from their own 'dealloc'. With very careful coding, Andreas *might* be able to make this kind of thing safe *for the part of the object behavior that he controls*, but he can't make it safe for the parts he doesn't control (e.g. behavior inherited from the frameworks).

Right I'd missed that because I'd originally commented on what his first post said his code was, which was an explicit unregister by the observed object on behalf of the observing object (which he'd retained) during the dealloc of the observed object. Now I see his clarification that he's been deallocating the dictionary of objects and using that dealloc to trigger the unregistration from the observing objects side - and yes I agree that's wrong. That's why I asked how he knew what to unregister, because you usually don't know who's listening to you.


I would agree that assuming the dealloc of the child object will occur as you release the dictionary of them at the start of your dealloc method and unregister all the observers for you is wrong, even in a retain/release sense, any object can have been retained by some piece of the framework to be deallocated much later.


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.

Now this I don't understand. If you enter your dealloc method with observers registered on yourself and do have a *safe* mechanism of ensuring they are completely removed before ending the dealloc routine (or calling [ super dealloc ] ) I don't see where the issue should lie. Can you point me to the note on that please too. I suppose if you did permit this you're sending a message to an object whilst it's being deallocated however the KVO registration methods are supplied by the NSObject superclass, who's dealloc method has not yet been called.


By *safe* there I mean that you know all the objects potentially observing you, they are all retained by you at this point (which in this posters case I believe they are) and you send them all a message on your own interface they all implement which says "I'm dying now - stop looking at me" and they unregister their observations of you before you release them.

Again however if you know who all your children are, and you say you do because you have them in a dictionary, why use KVO? You could as easily, each time a property they are likely to care about changes, iterate your dictionary of them and send them a custom message on a custom interface telling them so. They can choose to ignore it or not. When you are dealloc'ed your dictionary goes away and you stop sending things. It's kind of like a poor-man's KVO. _______________________________________________

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


  • Follow-Ups:
    • Re: Get error message about registered observers when Object receives dealloc message
      • From: Graham Cox <email@hidden>
References: 
 >Get error message about registered observers when Object receives dealloc message (From: Andreas Grosam <email@hidden>)
 >Re: Get error message about registered observers when Object receives dealloc message (From: Roland King <email@hidden>)
 >Re: Get error message about registered observers when Object receives dealloc message (From: Andreas Grosam <email@hidden>)
 >Re: Get error message about registered observers when Object receives dealloc message (From: Roland King <email@hidden>)
 >Re: Get error message about registered observers when Object receives dealloc message (From: Quincey Morris <email@hidden>)

  • Prev by Date: enabling/ disabling a uitextfield
  • Next by Date: Re: Correct way to have nil undo manager in Core Data document?
  • Previous by thread: Re: Get error message about registered observers when Object receives dealloc message
  • Next by thread: Re: Get error message about registered observers when Object receives dealloc message
  • Index(es):
    • Date
    • Thread