• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
NSFontPanel swamping the responder chain (and crashing)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSFontPanel swamping the responder chain (and crashing)


  • Subject: NSFontPanel swamping the responder chain (and crashing)
  • From: Graham Cox <email@hidden>
  • Date: Wed, 20 May 2015 10:22:33 +1000

I’m noticing something odd. When NSFontPanel is visible, it calls -[NSApplication targetForAction:to:from:] excessively often - in fact on every movement of the mouse. The action is -validModesForFontPanel: and the target is nil, so this is being pushed up the responder chain all of the time.

This seems to me a huge waste of time and CPU cycles, though it may have its reasons.

Why it’s a problem is that I’m experiencing a crash after I close a document due to this invocation - before the document is fully torn down, NSFontPanel sends this message and the responder chain appears to have, at that point, a stale reference to something in my doc*, so it crashes.

*this is the theory I’m working on, though it’s hard to be sure. Note that turning on NSZombies doesn’t show what the original target of the call was - it still crashes in the same way.

The stack trace is:

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000018

Application Specific Information:
objc_msgSend() selector name: respondsToSelector:


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	0x00007fff909040dd objc_msgSend + 29
1   com.apple.AppKit              	0x00007fff8fb30f74 _objectFromResponderChainWhichRespondsToAction + 227
2   com.apple.AppKit              	0x00007fff8fb30ac0 _NSTargetForSendAction + 2861
3   com.apple.AppKit              	0x00007fff8fb2fe3e -[NSApplication targetForAction:to:from:] + 329
4   com.mapdiva.as.artboard       	0x0000000105a3103a 0x1059ba000 + 487482
5   com.apple.AppKit              	0x00007fff8fdba102 -[NSFontPanel _canShowEffects] + 44
6   com.apple.AppKit              	0x00007fff8fdba0bb -[NSFontPanel _showEffects] + 31
7   com.apple.AppKit              	0x00007fff8fdb9675 -[NSFontPanel windowDidUpdate:] + 537
8   com.apple.CoreFoundation      	0x00007fff94c5245c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
9   com.apple.CoreFoundation      	0x00007fff94b42634 _CFXNotificationPost + 3140
10  com.apple.Foundation          	0x00007fff9a2e49d1 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
11  com.apple.CoreFoundation      	0x00007fff94bc7d80 -[NSArray makeObjectsPerformSelector:] + 496
12  com.apple.AppKit              	0x00007fff8f9eb5ea -[NSApplication(NSWindowCache) _updateWindowsUsingCache] + 495
13  com.apple.AppKit              	0x00007fff8f9eb399 -[NSApplication updateWindows] + 70
14  com.apple.AppKit              	0x00007fff8fde081f __38-[NSApplication setWindowsNeedUpdate:]_block_invoke2510 + 76
15  com.apple.CoreFoundation      	0x00007fff94bb2127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
16  com.apple.CoreFoundation      	0x00007fff94bb2080 __CFRunLoopDoObservers + 368
17  com.apple.CoreFoundation      	0x00007fff94ba4188 __CFRunLoopRun + 872
18  com.apple.CoreFoundation      	0x00007fff94ba3bd8 CFRunLoopRunSpecific + 296
19  com.apple.HIToolbox           	0x00007fff99fd556f RunCurrentEventLoopInMode + 235
20  com.apple.HIToolbox           	0x00007fff99fd51ee ReceiveNextEventCommon + 179
21  com.apple.HIToolbox           	0x00007fff99fd512b _BlockUntilNextEventMatchingListInModeWithFilter + 71
22  com.apple.AppKit              	0x00007fff8f9e99bb _DPSNextEvent + 978
23  com.apple.AppKit              	0x00007fff8f9e8f68 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346
24  com.apple.AppKit              	0x00007fff8f9debf3 -[NSApplication run] + 594
25  com.apple.AppKit              	0x00007fff8f95b354 NSApplicationMain + 1832


The only code of mine involved is at line 4 which is where I overrode targetForAction:to:from to see what was being called from where, and then calls super.

Anyone else noticed this, and what can be done about it? I need to make sure this doesn’t crash at the very least, but it also seems to indicate a deeper bug in that NSFontPanel is being extremely wasteful and suboptimal.

—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


  • Follow-Ups:
    • Re: NSFontPanel swamping the responder chain (and crashing)
      • From: Kyle Sluder <email@hidden>
    • Re: NSFontPanel swamping the responder chain (and crashing)
      • From: Graham Cox <email@hidden>
  • Prev by Date: Re: Tracking the retain count
  • Next by Date: Re: NSFontPanel swamping the responder chain (and crashing)
  • Previous by thread: Plugin bundle with Javascript
  • Next by thread: Re: NSFontPanel swamping the responder chain (and crashing)
  • Index(es):
    • Date
    • Thread