Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work
Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work
- Subject: Re: Trying to understand/prevent crash using restorableStateKeyPaths in NSPersistentUI Work
- From: Lee Ann Rucker <email@hidden>
- Date: Mon, 29 Jul 2013 22:05:14 -0700
On Jul 29, 2013, at 9:22 PM, Quincey Morris wrote:
> On Jul 29, 2013, at 21:03 , Lee Ann Rucker <email@hidden> wrote:
>
>> The main thread got stopped shortly after the first call to [wc window] - not in any restorable value's setter, though; that would've been obvious - but the actual crash was in a different thread. It's definitely at a point where one or more restorable values would already have been set.
>>
>> I close my windows by the equivalent of
>> [[wc window] setDelegate:nil]; // delegate is not the windowController.
>> [wc close];
>> [wc release];
>
> I don't understand whether you're saying you get a crash after closing the window (which is how I understand Eric's problem), or after the state is restored (i.e. when the window is re-opened, more or less).
The repro case is to close the document and then reopen it. It doesn't reopen the windows, it makes a new window of the same class as the old one. Looking at Instruments right now I have one new window and windowController - stopped in the window creation code - and one old window that would've been dealloc'ed if the code had just run a bit longer.
The window and windowController are closed with the above code, all references from my code to document, windowController, and window are cleared, and then the reopened document gets a new windowController. Immediately after the first call to [wc window] and all the side effects that triggers, NSPersistentUI crashes in another thread with:
* thread #14: tid = 0x3003, 0x00007fff94d3be90 libobjc.A.dylib`objc_msgSend + 16, stop reason = EXC_BAD_ACCESS (code=13, address=0x0)
frame #0: 0x00007fff94d3be90 libobjc.A.dylib`objc_msgSend + 16
frame #1: 0x00007fff94d3c04c libobjc.A.dylib`objc_msgSend_fixup + 204
frame #2: 0x00007fff8f915f61 Foundation`-[NSConcreteMapTable grow] + 652
frame #3: 0x00007fff8f90f481 Foundation`-[NSConcreteMapTable setObject:forKey:] + 168
frame #4: 0x00007fff8d079e60 AppKit`-[NSPersistentUIManager addPendingKeyPath:forObject:] + 203
frame #5: 0x00007fff8d07d1fc AppKit`__-[NSPersistentUIManager observeValueForKeyPath:ofObject:change:context:]_block_invoke_1 + 67
frame #6: 0x00007fff8b727a82 libdispatch.dylib`_dispatch_call_block_and_release + 18
frame #7: 0x00007fff8b7292d2 libdispatch.dylib`_dispatch_queue_drain + 264
frame #8: 0x00007fff8b72912e libdispatch.dylib`_dispatch_queue_invoke + 54
>
>> Never considered clearing the windowController; what effect would that have on the window?
>
> I'm not sure you can/should try to change that property yourself. But I kind of mis-stated my point. I was trying to say that window might have non-owning references to the window controller. If those references exist (such as in self.delegate) after the window controller is deallocated, you're clearly vulnerable to a crash. You might avoid this by ensuring the references no longer exist (manually clearing window.delegate, and perhaps the window controller itself clears the windowController property in its dealloc). OTOH, it might not be the dangling reference causing the problem, but rather the need to extend the life of the window controller. All this conditionality makes the point hard to say, which is why I'm probably not saying it very well.
The window delegate and windowController are different objects. I have complicated windows :)
_______________________________________________
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