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: Ken Thomases <email@hidden>
- Date: Tue, 19 May 2015 23:54:53 -0500
On May 19, 2015, at 9:26 PM, Graham Cox <email@hidden> wrote:
> Just to be clear: it crashes when there is no involvement of my code at all - this is the stack trace without the override, but with zombies enabled:
>
> Crashed Thread: 0 Dispatch queue: com.apple.main-thread
>
> Exception Type: EXC_BREAKPOINT (SIGTRAP)
> Exception Codes: 0x0000000000000002, 0x0000000000000000
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0 com.apple.CoreFoundation 0x00007fff91e9fd20 ___forwarding___ + 768
> 1 com.apple.CoreFoundation 0x00007fff91e9f998 _CF_forwarding_prep_0 + 120
> 2 com.apple.AppKit 0x00007fff8cdf23c7 -[NSWindow supplementalTargetForAction:sender:] + 240
> 3 com.apple.AppKit 0x00007fff8cdf1f74 _objectFromResponderChainWhichRespondsToAction + 227
> 4 com.apple.AppKit 0x00007fff8cdf1ac0 _NSTargetForSendAction + 2861
> 5 com.apple.AppKit 0x00007fff8cdf0e3e -[NSApplication targetForAction:to:from:] + 329
> 6 com.apple.AppKit 0x00007fff8d07b102 -[NSFontPanel _canShowEffects] + 44
> 7 com.apple.AppKit 0x00007fff8d07b0bb -[NSFontPanel _showEffects] + 31
> 8 com.apple.AppKit 0x00007fff8d07a675 -[NSFontPanel windowDidUpdate:] + 537
> 9 com.apple.CoreFoundation 0x00007fff91f1345c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
> 10 com.apple.CoreFoundation 0x00007fff91e03634 _CFXNotificationPost + 3140
> 11 com.apple.Foundation 0x00007fff975a59d1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
> 12 com.apple.CoreFoundation 0x00007fff91e88d80 -[NSArray makeObjectsPerformSelector:] + 496
> 13 com.apple.AppKit 0x00007fff8ccac5ea -[NSApplication(NSWindowCache) _updateWindowsUsingCache] + 495
> 14 com.apple.AppKit 0x00007fff8ccac399 -[NSApplication updateWindows] + 70
> 15 com.apple.AppKit 0x00007fff8d0a181f __38-[NSApplication setWindowsNeedUpdate:]_block_invoke2510 + 76
> 16 com.apple.CoreFoundation 0x00007fff91e73127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
> 17 com.apple.CoreFoundation 0x00007fff91e73080 __CFRunLoopDoObservers + 368
> 18 com.apple.CoreFoundation 0x00007fff91e65188 __CFRunLoopRun + 872
> 19 com.apple.CoreFoundation 0x00007fff91e64bd8 CFRunLoopRunSpecific + 296
> 20 com.apple.HIToolbox 0x00007fff9729656f RunCurrentEventLoopInMode + 235
> 21 com.apple.HIToolbox 0x00007fff972961ee ReceiveNextEventCommon + 179
> 22 com.apple.HIToolbox 0x00007fff9729612b _BlockUntilNextEventMatchingListInModeWithFilter + 71
> 23 com.apple.AppKit 0x00007fff8ccaa9bb _DPSNextEvent + 978
> 24 com.apple.AppKit 0x00007fff8cca9f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
> 25 com.apple.AppKit 0x00007fff8cc9fbf3 -[NSApplication run] + 594
> 26 com.apple.AppKit 0x00007fff8cc1c354 NSApplicationMain + 1832
>
>
>
> At line 2, it’s clearly trying to access a NSWindow zombie.
I'm not sure that's true. I think if the window were the zombie, the crash would not show a frame in an NSWindow method, it would occur at the point where that method was called. I suspect the problem is that the window is trying to check with its delegate/controller to see if it might respond to the action and the delegate/controller is the zombie. If I'm right, the problem could probably be solved by clearing the window's delegate property in the -dealloc of the delegate/controller object.
There should be a log message written which will clarify. It might or might not get included in the crash report, but it should be in the console log. What does that say?
> I’m pretty sure this is the window I just closed that closed the document. It’s hard to be 100% certain because the same result does not arise in the debugger - I have to export a complete app to see the problem, so I can’t examine the window’s address directly.
Exporting a complete app is not mutually exclusive of running the app under the debugger. You can tell Xcode to run the exported app when debugging by mucking with the scheme. Or, you can directly run it using lldb from the command line.
Does the problem also not happen if you run the app under Instruments with the Zombies template? If it does happen, that will help identify the history of the zombie.
If you're just using NSZombieEnabled=YES and running from the command line, you can also use MallocStackLoggingNoCompact=1. When the breakpoint/trap occurs, you can use the malloc_history tool to examine the history of the address of the zombie object.
Regards,
Ken
_______________________________________________
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