This was held for moderation for being too large (for some reason), so I've trimmed it and resent it.
>> >> 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? > > I think there's a bit more information here than you think. > > Yes, the view controller is being messaged because your window is processing > an event. I'll come back to this in a minute. > > First, we can winnow the history in two stages: > > -- Ignore the retain and release from 'tearDown', since those are balanced. > > -- Ignore the retain/autorelease from 'controlsTabBarController' and the > balancing release in 'drain'. > > That leaves this: > >> 2115 0x10a395410 MHControlsTabBarController Release 1 >> 03:29.825.784 0 TeXnicle -[TeXProjectDocument >> setControlsTabBarController:] > > and there's every indication this is the 'self.controlsTabBarController = > nil' you showed earlier in your message. Since the retain count goes from 1 > to 0 here, there shouldn't be any remaining references to the view > controller. But there is one, as your crash proves. There are two > possibilities: > > 1. You have a simple memory management bug where you overreleased the view > controller, likely when you initially put its value in the > '_controlsTabBarController' ivar (or whatever it's called) that backs the > "controlsTabBarController" property. I always use self.controlsTabBarController - I don't directly access the backing ivar anywhere. > > 2. The remaining reference is unretained. > > If it's #1, it shouldn't be too hard to find. At worst, you might have to go > through the whole Instruments history matching things. > > If it's #2, it can be harder to find, but the 'sendEvent:' message is an > excellent clue. Why would a window, dispatching an incoming event, send a > message to a view controller? Well, normally it won't. It's going to > transform the event into a NSResponder message and send it to something in > the responder chain, and normally view controllers *aren't* in the responder > chain. > > But it does send it to the view controller! My conclusion is that you put the > view controller in the responder chain yourself, and you forgot to take it > out. This accords with #2, because it's unlikely you *retained* the view > controller before adding it to the responder chain. Ahh, this may be going in the right direction. I do: self.controlsTabBarController = [[MHControlsTabBarController alloc] init]; [self.controlsTabBarController setNextResponder:self.mainWindow.nextResponder]; [self.mainWindow setNextResponder:self.controlsTabBarController]; So I should explicitly remove self.controlsTabBarController from the responder chain in my -tearDown method? OK, in my -tearDown I've inserted [self.mainWindow setNextResponder:self.controlsTabBarController.nextResponder]; before doing [self.controlsTabBarController tearDown]; self.controlsTabBarController = nil; After a short amount of testing, I haven't had a crash. So the frequency, at least, has reduced. Maybe this even fixes the problem. Under the Zombies Instrument, I no longer get a zombie when closing documents. > > Note that I say "you", but it might of course have been done by a 3rd party > library or some code you don't have direct knowledge of. No, probably 'you' was correct here. > > Anyway I would suggest you investigate both #1 (by further examining your > code for memory management errors, and winnowing the full Instruments history > of the object) and #2 (to understand which presumably-unretained reference is > being used for the zombie messaging). > > Looking forward to your further thoughts on this, Martin _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
