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 05:11:37 +0000
On May 20, 2015, at 21:53 , Graham Cox <email@hidden> wrote:
>
> I presume because the document owns its window controllers this must be weak to avoid a retain cycle.
That was my first thought, too, but then I realized that closing a document causes the ‘windowControllers’ array to be emptied, which would be a perfect time to break any retain cycles. I think it’s unsafe_unreleased just because it’s a million years old.
> Right. Forgive my sluggishness but I (eventually) arrived at this conclusion as well.
Yes, sorry, our posts crossed in transmission.
> That makes me wonder whether the window here is NOT the document’s main window, but the Save Panel? Maybe a sandboxed save panel (being the bizarre object it is) keeps a reference to the document it was attached to, and that is what is stale?
I doubt this would manifest as a stale pointer in a property called “document”.
> Is there a way to reveal the address/identity of a given object in Instruments? I see the NSWindow method in the stack trace, but it doesn’t tell me which window.
I would be inclined to try putting a breakpoint at the -[NSWindow supplementalTargetForAction:sender:] method, and poke around once there. Easier than Instruments, I’d imagine.
Incidentally, the thing that caused your document object’s reference count to go to 0 was not the close itself, but the removal of an observer ([_NSEventObserver dealloc]) that appears to be related to autosave. So the actual timing of dealloc (and perhaps other things like the zeroing of the “document” property) may be deferred by the autosave mechanism, and that might explain why the problem isn’t straightforwardly reproducible in a test app.
_______________________________________________
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