> On 21 May 2015, at 5:45 pm, Quincey Morris
> <quinceymor...@rivergatesoftware.com> wrote:
>
> On May 21, 2015, at 00:18 , Graham Cox <graham....@bigpond.com> 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 (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
