On Jul 29, 2013, at 9:22 PM, Quincey Morris wrote:
> On Jul 29, 2013, at 21:03 , Lee Ann Rucker <lruc...@vmware.com> 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 (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
