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

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

Committed: https://crrev.com/227b4c54986e2a60c85fcdf880465963f32901db
Cr-Commit-Position: refs/heads/master@{#426366}

[Robert Sesek, 2016-10-19 21:42:30]

Description was changed from

==========
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
==========

to

==========
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
==========

[Mark Mentovai, 2016-10-19 23:01:39]

LGTM

https://codereview.chromium.org/2435863002/diff/20001/chrome/browser/chrome_b...
File chrome/browser/chrome_browser_application_mac.mm (right):

https://codereview.chromium.org/2435863002/diff/20001/chrome/browser/chrome_b...
chrome/browser/chrome_browser_application_mac.mm:275: #if
!defined(MAC_OS_X_VERSION_10_12) || \
#include <AvailabilityMacros.h>

https://codereview.chromium.org/2435863002/diff/20001/chrome/browser/chrome_b...
chrome/browser/chrome_browser_application_mac.mm:276:
MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_12
Match what the SDK does by working __LP64__ into the mix, in case that ever
becomes something relevant again. Because the way things have been going, maybe
it will.

[Robert Sesek, 2016-10-19 23:22:12]

https://codereview.chromium.org/2435863002/diff/20001/chrome/browser/chrome_b...
File chrome/browser/chrome_browser_application_mac.mm (right):

https://codereview.chromium.org/2435863002/diff/20001/chrome/browser/chrome_b...
chrome/browser/chrome_browser_application_mac.mm:275: #if
!defined(MAC_OS_X_VERSION_10_12) || \
On 2016/10/19 23:01:39, Mark Mentovai wrote:
> #include <AvailabilityMacros.h>

Done.

https://codereview.chromium.org/2435863002/diff/20001/chrome/browser/chrome_b...
chrome/browser/chrome_browser_application_mac.mm:276:
MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_12
On 2016/10/19 23:01:39, Mark Mentovai wrote:
> Match what the SDK does by working __LP64__ into the mix, in case that ever
> becomes something relevant again. Because the way things have been going,
maybe
> it will.

That would be exciting. Done.

[Robert Sesek, 2016-10-19 23:22:20]

The CQ bit was checked by rsesek@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-19 23:23:00]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-20 00:15:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-20 00:15:24]

Dry run: This issue passed the CQ dry run.

[Robert Sesek, 2016-10-20 00:38:09]

The CQ bit was checked by rsesek@chromium.org

[Robert Sesek, 2016-10-20 00:38:09]

The patchset sent to the CQ was uploaded after l-g-t-m from mark@chromium.org
Link to the patchset: https://chromiumcodereview.appspot.com/2435863002/#ps40001
(title: "__LP64__")

[commit-bot: I haz the power, 2016-10-20 00:38:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-20 01:22:59]

Description was changed from

==========
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
==========

to

==========
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
==========

[commit-bot: I haz the power, 2016-10-20 01:23:00]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-10-21 13:14:17]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/227b4c54986e2a60c85fcdf880465963f32901db
Cr-Commit-Position: refs/heads/master@{#426366}
==========

[commit-bot: I haz the power, 2016-10-21 13:14:17]

Patchset 3 (id:??) landed as
https://crrev.com/227b4c54986e2a60c85fcdf880465963f32901db
Cr-Commit-Position: refs/heads/master@{#426366}