(resent) On Jan 25, 2013, at 07:52 , Martin Hewitson <martin.hewit...@aei.mpg.de> wrote:
> 2111 0x10a395410 MHControlsTabBarController Retain 2 > 03:29.823.791 0 TeXnicle -[TeXProjectDocument > controlsTabBarController] > 2112 0x10a395410 MHControlsTabBarController Autorelease > 03:29.823.792 0 TeXnicle -[TeXProjectDocument > controlsTabBarController] > 2113 0x10a395410 MHControlsTabBarController Retain 3 > 03:29.823.792 0 TeXnicle -[TeXProjectDocument tearDown] > 2114 0x10a395410 MHControlsTabBarController Release 2 > 03:29.825.781 0 TeXnicle -[TeXProjectDocument tearDown] > 2115 0x10a395410 MHControlsTabBarController Release 1 > 03:29.825.784 0 TeXnicle -[TeXProjectDocument > setControlsTabBarController:] > 2116 0x10a395410 MHControlsTabBarController Release 0 > 03:29.877.132 0 Foundation -[NSAutoreleasePool drain] > 2117 0x10a395410 MHControlsTabBarController Zombie -1 > 03:31.405.789 0 AppKit -[NSWindow sendEvent:] > > 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. 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. 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. 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). _______________________________________________ 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
