Re: Zombie object being messaged - why?
Re: Zombie object being messaged - why?
- Subject: Re: Zombie object being messaged - why?
- From: Keary Suska <email@hidden>
- Date: Fri, 25 Jan 2013 10:30:59 -0700
On Jan 25, 2013, at 8:52 AM, Martin Hewitson wrote:
> In a document based app running under ARC, I've been struggling for an eternity to get to the bottom of an occasional crash which happens when closing a document. I've spent a huge amount of time working on my -tearDown procedure which I call in my NSDocument subclass' -windowWillClose: and which subsequently calls -tearDown on many other app components. I also hit the same crash:
>
> [MHControlsTabBarController performSelector:withObject:]: message sent to deallocated instance 0x1075d2cb0
First things first--you are getting a crash, which means that the debugger should put you exactly in the place where you can inspect the arguments being sent via this method which will likely tell you what object is sending it and potentially why. Without this knowledge, everything you do is just random stabs and may not solve the problem even if it seems to go away.
Just a quick suggestion--have you searched your code to see if you ever call this method?
> MHControlsTabBarController is a view controller whose view is added to the document's main window when the document loads.
>
> In my document's -tearDown I do:
>
> // clean up tab bar controls
> [self.controlsTabBarController tearDown];
> self.controlsTabBarController = nil;
>
> In [MHControlsTabBarController tearDown] I nil out various state variables. I've also tried various things in that -tearDown, like removing the view controller's view from the superview, cancelling any run loop performs by doing:
>
> [[NSRunLoop currentRunLoop] cancelPerformSelectorsWithTarget:self];
> [[NSRunLoop mainRunLoop] cancelPerformSelectorsWithTarget:self];
IIRC performSelector:withObject: is not a run loop action--it is immediate dispatch, so doing the above is one of those useless stabs I mentioned.
> nilling out all IBOutlets, etc, but nothing helps so far.
> Should I interpret this as a window trying to message the object? Am I somehow over-reasling? Under ARC, I can't, right? If it's not coming from a window, how can I figure out which object is trying to message this deallocated MHControlsTabBarController?
If you are using ARC, I don't think you should be doing any explicit memory management except to explicitly balance other explicit memory management calls; and if you aren't, then you aren't over-releasing. Minimally, some object has a weak reference to your MHControlsTabBarController, and that can happen, so once you know who and why you can prevent it.
> There are a number of timer-based activities which check the state of this controls controller but in the document's -tearDown I try to stop all timers. The problem is, how can I ensure that all timers (and any actions already triggered) have stopped, before I go ahead tearing down everything else? I sort of need to delay the document closing somehow, but I asked about this in an earlier thread (this has been a loooong story) and was advised (probably rightly) that this was bad design. But this seems like a general problem to me, for which there is surely a general pattern which solves it. If I have timer-based activities, how do I make sure they are stopped before the rug is pulled from under their feet?
Whichever object set up the timers should invalidate them before their target would be released, so the validity of the target should be known and deterministic to that object. Sometimes easier said than done, but there it is. In any case it is not likely that a timer is responsible since they are supposed to retain or maintain a strong reference to their target until they are invalidated, after which time they would not fire anyway.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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