Re: NSFontPanel swamping the responder chain (and crashing)
Re: NSFontPanel swamping the responder chain (and crashing)
- Subject: Re: NSFontPanel swamping the responder chain (and crashing)
- From: Quincey Morris <email@hidden>
- Date: Thu, 21 May 2015 09:31:39 +0000
On May 21, 2015, at 01:33 , Graham Cox <email@hidden> wrote:
>
> Therefore either the crash is not due to window.windowController.document being stale after all,
According to Instruments, there’s only one NSWindow object ever been allocated, and only one NSWindowController, and both were created when the document was opened. I was going to say that the only possible route from that window to that document is window.windowController.document (apart from something so internal to Cocoa that we have no hope of deducing it). However, there is actually one more possibility: window.delegate. If that’s set to the document rather than the window controller, I suppose that might account for the crash. But I can’t imagine it would be.
> or something’s putting that reference back after the window controller is removed (which would be very strange).
> windowController.document = nil;
It might be worth checking that setting it to nil isn’t ignored.
> Or the window/windowController that’s crashing isn’t this one at all- it may as I suggested before be the Save panel
Instruments seems to confirm that the Save panel is in a different process’s address space, so I don’t see how to get here from there.
We start at the window (your window) and end at the document (the zombie). What chain of references comes in the middle I don’t know for sure, but the end-points seem to be a given.
_______________________________________________
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