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: Graham Cox <email@hidden>
- Date: Thu, 21 May 2015 18:33:26 +1000
> On 21 May 2015, at 5:45 pm, Quincey Morris <email@hidden> wrote:
>
> On May 21, 2015, at 00:18 , Graham Cox <email@hidden> wrote:
>>
>> How did you determine that it’s this property that is stale?
>
> Er, I think it was a deduction.
Ah, fair enough. It was my deduction as well, but I thought you’d arrived there by a more sure route. At least we’re thinking the same way… and I do appreciate your help by the way.
I do wonder if this deduction is correct though. Here’s a bit of evidence to the contrary.
I overrode -removeWindowController: in my document and I force the controller’s document reference to be nil:
- (void) removeWindowController:(NSWindowController*) windowController
{
NSLog(@"removing window controller %@, window=%@", windowController, windowController.window );
[windowController retain];
[super removeWindowController:windowController];
windowController.document = nil;
[windowController release];
}
This doesn’t interfere with the normal deallocation of the document, but it stll goes and crashes exactly the same. Therefore either the crash is not due to window.windowController.document being stale after all, or something’s putting that reference back after the window controller is removed (which would be very strange). Or the window/windowController that’s crashing isn’t this one at all- it may as I suggested before be the Save panel (the crash only occurs if the save panel is made to appear by dirtying the document and setting the system pref to review unsaved changes).
Log output:
2015-05-21 18:22:10.702 Artboard[26228:1678806] window closing: <NSWindow: 0x6080001f1600>
2015-05-21 18:22:10.702 Artboard[26228:1678806] -[GCOrteliusDocument<0x101108ab0> cleanUpIfNeeded].406 window closing, cleaning up. Doc: <GCOrteliusDocument: 0x101108ab0>
2015-05-21 18:22:10.727 Artboard[26228:1678806] removing window controller <NSWindowController: 0x608000087fd0>, window=<NSWindow: 0x6080001f1600>
2015-05-21 18:22:10.737 Artboard[26228:1678806] -[GCOrteliusDocument<0x101108ab0> dealloc].1121 deallocating DKDrawingDocument <GCOrteliusDocument: 0x101108ab0>
2015-05-21 18:22:10.743 Artboard[26228:1678806] *** -[GCOrteliusDocument respondsToSelector:]: message sent to deallocated instance 0x101108ab0
> Oh, yeah, I didn’t think of that. Perhaps you can leave the breakpoint disabled until you hit another breakpoint at a close method, or something like that.
I can’t do a ‘po self’, even just typing it in, at this point, no matter how cunning I am at breaking at the right time. It seems as if there really isn’t enough info to resolve ‘self’ (the message is "error: use of undeclared identifier ‘self’")
As you suggest, it’s probably a register, but don’t know which. I get the same error if I try any of them - undeclared identifier ‘r15’ for example.
Might this strengthen the argument that this window/controller is not what was assumed? If it’s a PowerBox object, maybe that’s why the debugger refuses to divulge any information about it?
Recall also that the non-sandboxed version doesn’t crash either.
> Or live dangerously and override ‘supplementalTargetForAction:sender:’?
Might have to - even though it’s a pain to insert a custom window controller between a document and its window. However I’m beginning to think it’s not going to help.
—Graham
_______________________________________________
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