[Mac] Redo NSException handling, and generate better stacks for C++ exceptions.
This introduces base::mac::CallWithEHFrame(), which will run a block in a
stack frame that is set up to stop searching for an exception handler when it
is reached. This is used to prevent a top-level exception handler, installed
in CFRunLoopRunSpecific(), from catching and rethrowing C++ exceptions. When
it does this, the resulting stack traces are not useful for triage purposes. By
stoping the search for an exception handler, the runtime will call
std::terminate directly from the throwing stack trace.
In addition, NSException handling is converted from swizzling the designated
initializer to an ObjC 2.0 exception preprocessor.
Some exceptions could still escape this mechanism, if they are thrown
without CallWithEHFrame() on the stack. This could happen if the exception
were thrown outside of the MessagePump's work sources or -sendEvent:. Possible
situations are things like the CFRunLoop block and Mach port callouts. This
shouldn't happen from Chromium code, so it would only affect system-thrown
exceptions. These exceptions would still be fatal, just with the less-useful
run loop stack.
To summarize: all uncaught exceptions are fatal one way or another. If the
exception isn't caught before it unwinds to CallWithEHFrame, the crash will have
an immediately actionable stack from the point of throw. If the exception is
caught by the run loop or some other top-level exception handler, the exception
will be rethrown and the crash stack will be less useful. In that case, if it's
an ObjC exception, a crash key will still record a trace from the point-of-
throw. Using try/catch is now unrestricted, and no special whitelist is
maintained to allow certain NSExceptions to be alloc/init'd.
BUG=503128
R=shess@chromium.org, thakis@chromium.org
Review URL: https://codereview.chromium.org/1212093002
Cr-Commit-Position: refs/heads/master@{#338332}
9 files changed
