This crash first appeared on Mac on Dev release version: 53.0.2785.8.

Considering previous Dev(53.0.2774.3) as good build and below as the changelog:
================================================================================
https://chromium.googlesource.com/chromium/src/+log/53.0.2774.0..53.0.2785.0?pretty=fuller&n=10000

Suspecting: https://codereview.chromium.org/2069103004 to be the related change.

kirr@: Could you please take a look at these crashes.

Thank you!

Users experienced this crash on the following builds:

Mac Dev 54.0.2824.0 -  0.59 CPM, 2 reports, 2 clients (signature -[NSApplication _crashOnException:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Oh. Do you know WTR? Can I get more info somehow (I don't have an access to crash.corp.google.com)?
How did you get that it is mac_views crash?

Users experienced this crash on the following builds:

Mac Beta 53.0.2785.57 -  0.75 CPM, 4 reports, 3 clients (signature -[NSApplication _crashOnException:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

This is bucketing together a bunch of rare, unrelated exceptions fired from ObjectiveC code. I doubt r403166 is related.

> This crash first appeared on Mac on Dev release version: 53.0.2785.8.

Actually, it appears in all releases, once they are running on enough computers.

53.0.2785.8 has 1 crash
52.0.2743.116 has 3
52.0.2743.82 has 13
52.0.2743.60 has 1
51.0.2704.106 has 9
51.0.2704.103 has 23
50.0.2661.102 has 1

The interesting part is the spike that seems to have made these appear in Canary releases, starting with the 2785 branch (54.0.2786.0 and onwards all have a few of these). It's probably not coincidence that the m53 branch gets flagged -- r403545 landed in 2786 and was then merged to 2785. That made a class of exceptions that would previously pop a dialog asking the user to "Crash" or "Continue" to immediately crash.  I suspect the reports in m50..m52 are from users who selected "Crash". Now we crash by default, so there's a spike due to the fix on  Issue 624885 :


commit b296d953fe840f3cdf609bde2dc3de53baabae63
Author: mark <mark@chromium.org>
Date: Fri Jul 01 22:04:43 2016

mac: Crash on uncaught Objective-C exceptions routed to NSApplication


Most of these seem to be isolated. E.g.


54.0.2786.0, 2787, 2793(x4), 2794(x3), 2795
 - Crashing on exception: *** -[NSConcreteTask terminationStatus]: task not launched [10.11]

54.0.2786.0 
 - Crashing on exception: View is not in any window [10.11]

54.0.2789.0
 - Crashing on exception: -[NSView stopAnimation]: unrecognized selector sent to instance 0x7fd99b427fa0 [10.11]

54.0.2789.0
 - Crashing on exception: -[NSPopover showRelativeToRect:ofView:preferredEdge:]: nil view provided. You must supply a view. [10.10]

54.0.2790.0
 - Crashing on exception: CALayer position contains NaN: [66 nan] [10.11]

54.0.2790.0
 - Crashing on exception: -[FI_TColumnGroupHeaderCellView cell]: unrecognized selector sent to instance 0x7fbe20c898c0 [10.11]

54.0.2791.0
 - Crashing on exception: *** -[__NSArrayM removeObjectAtIndex:]: index 319 beyond bounds [0 .. 318] [10.10]

54.0.2795.0
 - Crashing on exception: CGSSetMenuBarCompanionWindow failure err: 268435459, for <NSToolbarFullScreenWindowManager: 0x7fd0502ea220> - Window: - attaches to menu bar - spaceID: 130 [***10.12***]
 - Crashing on exception: -[__NSCFType tableView:objectValueForTableColumn:row:]: unrecognized selector sent to instance 0x7f913b9caab0 [10.11]
 - Crashing on exception: *** -[__NSArrayM removeObjectAtIndex:]: index 14221 beyond bounds [0 .. 14220] [10.10]
  - Crashing on exception: *** -[__NSArrayM removeObjectAtIndex:]: index 46 beyond bounds [0 .. 45] [10.10]
...


These are all almost certainly AppKit bugs we can't do much about :/

I think the only low-hanging fruit here is to focus on the Sierra crashes - these represent a third of reports, even though Sierra shouldn't be that prevalent.

https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.magic_signature_1.name%3D%27-%5BNSApplication%20_crashOnException%3A%5D%27%20AND%20custom_data.ChromeCrashProto.os_family%3D%2710.12%20(Sierra)%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#samplereports:5,productversion

Then we start to see a pattern:

E.g. Sierra, 51.0.2704.106
 - 2x Crashing on exception: -[NSRemoteView _popoverDidExitFullscreen:]: unrecognized selector sent to instance 0x600000337520
 - 1x Crashing on exception: -[_NSThreadData _popoverDidExitFullscreen:]: unrecognized selector sent to instance 0x600000323ac0
 - 1x Crashing on exception: -[TabContentsContainerView _popoverDidExitFullscreen:]: unrecognized selector sent to instance 0x600000339be0
 - 4x Crashing on exception: -[__NSCFString _popoverDidEnterFullscreen:]: unrecognized selector sent to instance 0x608000526fe0
 - 1x Crashing on exception: -[TabStripBackgroundView _popoverDidEnterFullscreen:]: unrecognized selector sent to instance 0x60800033a860

But 87% of the Sierra crashes are in 10.12.0 16A254g, which is an early release - looks like Apple have fixed this bug.

I poked around at the reports on other Sierra releases, but they all fall into the buckets above.


Bouncing to mark@ for a second set of eyes, and since this is probably due to r403545. IMO there's nothing that we can really act on here, but we should watch out for new spikes, or strong patterns once m53 is out in Stable.


I guess one thing to consider is whether users who previously clicked "continue" on that dialog instead of "Crash" will now be unhappy since things are likely to just crash instead.

I think that the dialog only ever showed up in beta OS builds. In release OS builds, there was no dialog and the action was always “crash”. If we saw this increase following the fix for  bug 624885 , it could mean that we have a lot of users on beta OS builds.

I don’t think there’s anything to do here either. All of these seem to be AppKit bugs, there’s a heavy tilt toward unreleased OS builds, and the crashes would have been there all along anyway (and, honestly, rarely would have been continue-able, although clicking continue would probably change the bucketing).

These are bucketing a lot worse, and it's obvious why. From https://crash.corp.google.com/browse?q=reportid=%2703eefe8100000000%27#0, I decoded the firstexception_bt:

Crashing on exception: -[NSView stopAnimation]: unrecognized selector sent to instance 0x7fb90ea36420

0x01894553 [Google Chrome Framework -	 safe_conversions.h:77] base::debug::StackTrace::StackTrace()
0x01494184 [Google Chrome Framework -	 chrome_browser_application_mac.mm:107] chrome_browser_application_mac::(anonymous namespace)::ExceptionPreprocessor(objc_object*)
0x0001273c [libobjc.A.dylib +	 0x1273c] objc_exception_throw
0x0017f1ad [CoreFoundation +	 0x17f1ad] -[NSObject(NSObject) doesNotRecognizeSelector:]
0x00085571 [CoreFoundation +	 0x85571] ___forwarding___
0x000850f8 [CoreFoundation +	 0x850f8] __forwarding_prep_0___
0x03825d06 [Google Chrome Framework -	 download_shelf_controller.mm:155] -[DownloadShelfController browserWillBeDestroyed]
0x037ff85b [Google Chrome Framework -	 browser_window_controller.mm:448] -[BrowserWindowController dealloc]
0x000092f4 [libobjc.A.dylib +	 0x92f4] objc_object::sidetable_release(bool)
0x00058995 [AppKit +	 0x58995] -[NSWindowController release]
0x000016b1 [libsystem_blocks.dylib +	 0x16b1] _Block_release
0x000016b1 [libsystem_blocks.dylib +	 0x16b1] _Block_release
0x000016b1 [libsystem_blocks.dylib +	 0x16b1] _Block_release
0x0000a2e0 [libxpc.dylib +	 0xa2e0] _xpc_connection_call_reply
0x0000240b [libdispatch.dylib +	 0x240b] _dispatch_client_callout
0x00015c1c [libdispatch.dylib +	 0x15c1c] _dispatch_main_queue_callback_4CF
0x000ca9e9 [CoreFoundation +	 0xca9e9] __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__

Based on the original stack, _dispatch_client_callout must be doing the same kind of exception-catching garbage that they do in CFRunLoopRunSpecific:

Thread 0 CRASHED [EXC_BAD_INSTRUCTION / 0x00000001 @ 0x00007fff8408fe6a ] MAGIC SIGNATURE THREAD
0x00007fff8408fe6a	(AppKit + 0x003d0e6a )	-[NSApplication _crashOnException:]
0x00007fff8408fdc3	(AppKit + 0x003d0dc3 )	-[NSApplication reportException:]
0x00007fff86e1386a	(CoreFoundation + 0x0017c86a )	__handleUncaughtException
0x00007fff852c6487	(libobjc.A.dylib + 0x00016487 )	_objc_terminate()
0x00007fff8d89900d	(libc++abi.dylib + 0x0002400d )	std::__terminate(void (*)())
0x00007fff8d899082	(libc++abi.dylib + 0x00024082 )	std::terminate()
0x00007fff852c6229	(libobjc.A.dylib + 0x00016229 )	objc_terminate
0x00007fff8d64141e	(libdispatch.dylib + 0x0000241e )	_dispatch_client_callout
0x00007fff8d654c1b	(libdispatch.dylib + 0x00015c1b )	_dispatch_main_queue_callback_4CF
0x00007fff86d619e8	(CoreFoundation + 0x000ca9e8 )	__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
0x00007fff86d208dc	(CoreFoundation + 0x000898dc )	__CFRunLoopRun
0x00007fff86d1fed7	(CoreFoundation + 0x00088ed7 )	CFRunLoopRunSpecific
0x00007fff9a1fc934	(HIToolbox + 0x00030934 )	RunCurrentEventLoopInMode
0x00007fff9a1fc76e	(HIToolbox + 0x0003076e )	ReceiveNextEventCommon
0x00007fff9a1fc5ae	(HIToolbox + 0x000305ae )	_BlockUntilNextEventMatchingListInModeWithFilter
0x00007fff83d07df5	(AppKit + 0x00048df5 )	_DPSNextEvent
0x00007fff83d07225	(AppKit + 0x00048225 )	-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
0x00007fff83cfbd7f	(AppKit + 0x0003cd7f )	-[NSApplication run]
0x0000000110592c7d	(Google Chrome Framework -message_pump_mac.mm:665 )	base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*)
0x00000001105922b3	(Google Chrome Framework -message_pump_mac.mm:238 )	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x00000001105ac980	(Google Chrome Framework -run_loop.cc:35 )	base::RunLoop::Run()
0x0000000110172d84	(Google Chrome Framework -chrome_browser_main.cc:1967 )	ChromeBrowserMainParts::MainMessageLoopRun(int*)
0x000000010ef78e73	(Google Chrome Framework -browser_main_loop.cc:950 )	content::BrowserMainLoop::RunMainMessageLoopParts()
0x000000010ef7b451	(Google Chrome Framework -browser_main_runner.cc:155 )	content::BrowserMainRunnerImpl::Run()
0x000000010ef754be	(Google Chrome Framework -browser_main.cc:46 )	content::BrowserMain(content::MainFunctionParams const&)
0x0000000110131fd7	(Google Chrome Framework -content_main_runner.cc:785 )	content::ContentMainRunnerImpl::Run()
0x0000000110131235	(Google Chrome Framework -content_main.cc:20 )	content::ContentMain(content::ContentMainParams const&)
0x000000010ecdcde9	(Google Chrome Framework -chrome_main.cc:85 )	ChromeMain
0x000000010ea73d49	(Google Chrome Canary + 0x00000d49 )	
0x000000010ea73b33	(Google Chrome Canary + 0x00000b33 )	

If we check libdispatch, we can indeed see them doing that in _dispatch_client_callout() http://opensource.apple.com/source/libdispatch/libdispatch-501.40.12/src/object.m.

Our exception handling requires CallWithEHFrame to be on the stack in order go get usable stack traces (see  issue 503128  for more info). I don't see a good way to fix this client-side, unfortunately.

At the very least, we can teach the server that -[NSApplication _crashOnNSException:] should bucket under the [Cocoa Exception] bucket.

Users experienced this crash on the following builds:

Mac Canary 55.0.2841.0 -  0.52 CPM, 1 reports, 1 clients (signature -[NSApplication _crashOnException:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

Not much interesting to add here.. (still an AppKit bug we probably can't fix). But I did manage to trigger a bug that's getting bucketed with these, and have a flaky/racy repro case. This is the

"-[NSPopover showRelativeToRect:ofView:preferredEdge:]: nil view provided. You must supply a view. [10.10]" from #c5.

The 55.0.2881.0 Canary crashed for me on 10.11 - http://go/crash/06e1199900000000

Steps:
 - have unpacked extensions installed
 - Start Chrome
 - Click bookmark bubble (the Cocoa one, not the MacViews one)
 - Press Ctrl+Cmd+d to get a dictionary lookup
 - [racy part] the "unpacked extensions" popup appears, dismisses the bookmarks bubble
 - then the dictionary popup tries to appear, but the parent window has gone away

I think the event to trigger dismissal needs to occur before the event to trigger the dictionary lookup, so it's super-hard to reproduce this manually.

Users experienced this crash on the following builds:

Mac Canary 56.0.2885.0 -  2.72 CPM, 2 reports, 2 clients (signature -[NSApplication _crashOnException:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/227b4c54986e2a60c85fcdf880465963f32901db

commit 227b4c54986e2a60c85fcdf880465963f32901db
Author: rsesek <rsesek@chromium.org>
Date: Thu Oct 20 01:21:54 2016

Wrap -[BrowserCrApplication nextEventMatchingMask:…] with base::mac::CallWithEHFrame.

nextEventMatchingMask:… is what drives the CFRunLoop on the main thread. While
both -[NSApplication sendEvent:] and all the MessagePumpMac callouts are wrapped
in CallWithEHFrame, other system runloop callouts (like __CFMachPortPerform and
__NSFireDelayedPerform) are not wrapped.

If an exception is raised from within one of those callouts, it will bubble up
to -[NSApplication run], which then swallows the useful stacktrace via
-reportException:/-crashOnException:.

By wrapping nextEventMatchingMask:…, exceptions will generate better crash
stacktraces when raised from system callouts. However, exceptions raised from
libdispatch callouts will not be caught, due to another exception handler in
_dispatch_client_callout. See  https://crbug.com/637270#c7  for details.

BUG= 637270 
R=mark@chromium.org

Review-Url: https://chromiumcodereview.appspot.com/2435863002
Cr-Commit-Position: refs/heads/master@{#426366}

[modify] https://crrev.com/227b4c54986e2a60c85fcdf880465963f32901db/chrome/browser/chrome_browser_application_mac.mm

This crash still exist in minor #s even after the patch in #20 was landed in  
- 56.0.2897.0

Sample crash report
===================

go/crash/fe7dba8700000000

Thread 34 CRASHED [EXC_BAD_INSTRUCTION / EXC_I386_INVOP @ 0x00007fff91cb2510 ] MAGIC SIGNATURE THREAD
0x00007fff91cb2510	(AppKit + 0x003bb510 )	-[NSApplication _crashOnException:]
0x00007fff91cb246a	(AppKit + 0x003bb46a )	-[NSApplication reportException:]
0x00007fff906224ed	(CoreFoundation + 0x001644ed )	__handleUncaughtException
0x00007fff86dec7cc	(libobjc.A.dylib + 0x000127cc )	_objc_terminate()
0x00007fff916e90a0	(libc++abi.dylib + 0x000260a0 )	std::__terminate(void (*)())
0x00007fff916e8b2f	(libc++abi.dylib + 0x00025b2f )	__cxa_throw
0x00007fff86de8897	(libobjc.A.dylib + 0x0000e897 )	objc_exception_throw
0x00007fff906250ac	(CoreFoundation + 0x001670ac )	-[NSObject(NSObject) doesNotRecognizeSelector:]
0x00007fff9056ae23	(CoreFoundation + 0x000ace23 )	___forwarding___
0x00007fff9056a997	(CoreFoundation + 0x000ac997 )	__forwarding_prep_0___
0x000000012bf88754	(libLoader.dylib + 0x00001754 )	
0x00007fff6941ad4a	(dyld + 0x00012d4a )	
0x00007fff6941aed7	(dyld + 0x00012ed7 )	
0x00007fff694178d0	(dyld + 0x0000f8d0 )	
0x00007fff69417757	(dyld + 0x0000f757 )	
0x00007fff694179c8	(dyld + 0x0000f9c8 )	
0x00007fff6940d0c9	(dyld + 0x000050c9 )	
0x00007fff69414230	(dyld + 0x0000c230 )	
0xdeadbeee		
0x00007fff8f904fd6	(libsystem_pthread.dylib + 0x00003fd6 )	_pthread_start
0x00007fff8f9023ec	(libsystem_pthread.dylib + 0x000013ec )	thread_start

The CL is not to fix the crash. More statistics or sample reports are not necessary on this issue.

Users experienced this crash on the following builds:

Mac Canary 57.0.2926.0 -  0.28 CPM, 6 reports, 6 clients (signature -[NSApplication _crashOnException:])

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1e145dcb71a3bedf9fde398045cb8e54e244c3e3

commit 1e145dcb71a3bedf9fde398045cb8e54e244c3e3
Author: rsesek <rsesek@chromium.org>
Date: Wed Dec 07 19:40:27 2016

[Mac] Modify the ObjC exception preprocessor to make some exceptions fatal.

Various Cocoa routines in the event loop obscure exception stack traces
by catching-and-rethrowing exceptions, so that the original trace from
throwing the exception is lost.

To combat this, the ObjC exception preprocessor will now unwind the stack to
search for an exception handler. If it finds a stack frame with a handler, it
will check that the function's name is not on the sinkhole list. If it is on the
list, the preprocessor will make the exception fatal to produce a stack trace
from the point of throw. If it is not on the list, then the preprocessor will
not take action and will let the normal exception handling mechanism run.

The preprocessor works in conjunction with the base::mac::CallWithEHFrame
system. The preprocessor is only called for exceptions raised with objc_throw,
which C++ exceptions are not. Furthermore, some of the system routines that do
the catch-and-rethrow are higher on the stack than CallWithEHFrame, so it
cannot force those exceptions to be fatal at the point of throw.

This change also wraps -[BrowserCrApplication sendAction:to:from:] in
CallWithEHFrame().

BUG= 637270 
R=mark@chromium.org

Review-Url: https://codereview.chromium.org/2543813003
Cr-Commit-Position: refs/heads/master@{#437033}

[modify] https://crrev.com/1e145dcb71a3bedf9fde398045cb8e54e244c3e3/chrome/browser/BUILD.gn
[modify] https://crrev.com/1e145dcb71a3bedf9fde398045cb8e54e244c3e3/chrome/browser/chrome_browser_application_mac.h
[modify] https://crrev.com/1e145dcb71a3bedf9fde398045cb8e54e244c3e3/chrome/browser/chrome_browser_application_mac.mm
[delete] https://crrev.com/dce2716990a517afe2ba37ba8d698bc2d1f9529f/chrome/browser/chrome_browser_application_mac_unittest.mm
[add] https://crrev.com/1e145dcb71a3bedf9fde398045cb8e54e244c3e3/chrome/browser/mac/exception_processor.h
[add] https://crrev.com/1e145dcb71a3bedf9fde398045cb8e54e244c3e3/chrome/browser/mac/exception_processor.mm
[add] https://crrev.com/1e145dcb71a3bedf9fde398045cb8e54e244c3e3/chrome/browser/mac/exception_processor_unittest.mm
[modify] https://crrev.com/1e145dcb71a3bedf9fde398045cb8e54e244c3e3/chrome/test/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b1c93f15d1f0d15a575b6b491e5d5ef536e5a1f1

commit b1c93f15d1f0d15a575b6b491e5d5ef536e5a1f1
Author: rsesek <rsesek@chromium.org>
Date: Thu Dec 08 21:34:15 2016

[Mac] Set the nsexception crash key in TERMINATING_FROM_UNCAUGHT_NSEXCEPTION().

This was set previously back when the NSException initializers were swizzled,
and it can be used by the crash processor more easily than the
first/lastexception keys.

BUG= 637270 
R=mark@chromium.org

Review-Url: https://codereview.chromium.org/2561173002
Cr-Commit-Position: refs/heads/master@{#437350}

[modify] https://crrev.com/b1c93f15d1f0d15a575b6b491e5d5ef536e5a1f1/chrome/browser/mac/exception_processor.mm

This should bucket a lot better now, with the above changes and cl/141906316 for the processor. We may still get a few crashes into this bucket, but that's unavoidable given how the preprocessor works

Example:

https://crash.corp.google.com/browse?q=product.name%3D%27Chrome_Mac%27%20AND%20product.version%3D%2757.0.2965.0%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27browser%27%20AND%20custom_data.ChromeCrashProto.magic_signature_1.name%3D%27%5BCocoa%20Exception%5D%20-%5BDownloadShelfController%20browserWillBeDestroyed%5D%20raised%3A%20NSInvalidArgumentException%3A%20-%5BNSView%20stopAnimation%5D%3A%20unrecognized%20selector%20sent%20to%20instance%200x%23%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&stbtiq=&reportid=&index=0#0

Magic Signature: [Cocoa Exception] -[DownloadShelfController browserWillBeDestroyed] raised: NSInvalidArgumentException: -[NSView stopAnimation]: unrecognized selector sent to instance 0x#

0x000000010411c7b1	(Google Chrome Framework -debugger_posix.cc:260 )	base::debug::BreakDebugger()
0x00000001041353b9	(Google Chrome Framework -logging.cc:759 )	logging::LogMessage::~LogMessage()
0x0000000103d6897b	(Google Chrome Framework -exception_processor.mm:92 )	chrome::TERMINATING_FROM_UNCAUGHT_NSEXCEPTION(objc_object*)
0x0000000103d687c7	(Google Chrome Framework -exception_processor.mm:152 )	chrome::ObjcExceptionPreprocessor(objc_object*)
0x00007fff8b9c3f7d	(libobjc.A.dylib + 0x00010f7d )	objc_exception_throw
0x00007fff8d9a510c	(CoreFoundation + 0x0017f10c )	-[NSObject(NSObject) doesNotRecognizeSelector:]
0x00007fff8d8ab4d0	(CoreFoundation + 0x000854d0 )	___forwarding___
0x00007fff8d8ab057	(CoreFoundation + 0x00085057 )	__forwarding_prep_0___
0x00000001067aea25	(Google Chrome Framework -download_shelf_controller.mm:154 )	-[DownloadShelfController browserWillBeDestroyed]
0x000000010678522a	(Google Chrome Framework -browser_window_controller.mm:426 )	-[BrowserWindowController dealloc]
0x00007fff8b9bb287	(libobjc.A.dylib + 0x00008287 )	objc_object::sidetable_release(bool)
0x00007fff8911b994	(AppKit + 0x00058994 )	-[NSWindowController release]
0x00007fff9b0fc6b0	(libsystem_blocks.dylib + 0x000016b0 )	_Block_release
0x00007fff9b0fc6b0	(libsystem_blocks.dylib + 0x000016b0 )	_Block_release
0x00007fff9b0fc6b0	(libsystem_blocks.dylib + 0x000016b0 )	_Block_release
0x00007fff87fb42df	(libxpc.dylib + 0x0000a2df )	_xpc_connection_call_reply
0x00007fff8a94740a	(libdispatch.dylib + 0x0000240a )	_dispatch_client_callout
0x00007fff8a95ac1b	(libdispatch.dylib + 0x00015c1b )	_dispatch_main_queue_callback_4CF
0x00007fff8d8f0948	(CoreFoundation + 0x000ca948 )	__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__
0x00007fff8d8af83c	(CoreFoundation + 0x0008983c )	__CFRunLoopRun
0x00007fff8d8aee37	(CoreFoundation + 0x00088e37 )	CFRunLoopRunSpecific
0x00007fff8e785934	(HIToolbox + 0x00030934 )	RunCurrentEventLoopInMode
0x00007fff8e78576e	(HIToolbox + 0x0003076e )	ReceiveNextEventCommon
0x00007fff8e7855ae	(HIToolbox + 0x000305ae )	_BlockUntilNextEventMatchingListInModeWithFilter
0x00007fff8910bdf5	(AppKit + 0x00048df5 )	_DPSNextEvent
0x00007fff8910b225	(AppKit + 0x00048225 )	-[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
0x0000000103ceb70f	(Google Chrome Framework -chrome_browser_application_mac.mm:187 )	__71-[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:]_block_invoke
0x0000000104135f89	(Google Chrome Framework + 0x01994f89 )	base::mac::CallWithEHFrame(void () block_pointer)
0x0000000103ceb648	(Google Chrome Framework -chrome_browser_application_mac.mm:186 )	-[BrowserCrApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
0x00007fff890ffd7f	(AppKit + 0x0003cd7f )	-[NSApplication run]
0x0000000104145b5d	(Google Chrome Framework -message_pump_mac.mm:637 )	base::MessagePumpNSApplication::DoRun(base::MessagePump::Delegate*)
0x00000001041451db	(Google Chrome Framework -message_pump_mac.mm:210 )	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x0000000104163ad2	(Google Chrome Framework -run_loop.cc:37 )	base::RunLoop::Run()
0x0000000103cf1138	(Google Chrome Framework -chrome_browser_main.cc:1987 )	ChromeBrowserMainParts::MainMessageLoopRun(int*)
0x00000001034e24c3	(Google Chrome Framework -browser_main_loop.cc:1171 )	content::BrowserMainLoop::RunMainMessageLoopParts()
0x00000001034e5181	(Google Chrome Framework -browser_main_runner.cc:141 )	content::BrowserMainRunnerImpl::Run()
0x00000001034de06b	(Google Chrome Framework -browser_main.cc:46 )	content::BrowserMain(content::MainFunctionParams const&)
0x0000000103ca8ddf	(Google Chrome Framework -content_main_runner.cc:793 )	content::ContentMainRunnerImpl::Run()
0x0000000103ca80a5	(Google Chrome Framework -content_main.cc:20 )	content::ContentMain(content::ContentMainParams const&)
0x00000001027a3d7a	(Google Chrome Framework -chrome_main.cc:112 )	ChromeMain
0x000000010253ad99	(Google Chrome Canary + 0x00000d99 )	
0x00007fff8615a5ac	(libdyld.dylib + 0x000035ac )	
0x00007fff8615a5ac	(libdyld.dylib + 0x000035ac )	

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7f2f9fa01e93d95339d0773ce5dd527cbc717532

commit 7f2f9fa01e93d95339d0773ce5dd527cbc717532
Author: rsesek <rsesek@chromium.org>
Date: Tue Jan 24 17:19:27 2017

[Mac] Sinkhole __NSFireDelayedPerform and _CFXNotificationPost in the exception preprocessor.

BUG= 637270 
TEST=unit_tests --gtest_filter=ExceptionProcessorTest.*
R=mark@chromium.org

Review-Url: https://codereview.chromium.org/2649253003
Cr-Commit-Position: refs/heads/master@{#445748}

[modify] https://crrev.com/7f2f9fa01e93d95339d0773ce5dd527cbc717532/chrome/browser/mac/exception_processor.mm
[modify] https://crrev.com/7f2f9fa01e93d95339d0773ce5dd527cbc717532/chrome/browser/mac/exception_processor_unittest.mm

Issue still seen on Mac latest stable and loks slightly spiked on M57.

57.0.2987.110	0.43%	310	--M57(1% Stable)
57.0.2987.98	1.14%	826	
56.0.2924.87	32.30%	23339	--M56(100% stable)
56.0.2924.76	2.25%	1626	

Link to list of builds: https://goto.google.com/ntrvg
rsesek@: Could you please take a look into this.