Change signal, uncaught NSExceptions and Mach exception handlers to
prevent re-entrancy with a first-exception-wins approach to prevent
concurrent exceptions from trying to use the same cached intermediate
dump writer. Uses compare-and-swap to either return early for reentrant
signals or to wait indefinitely for anything after the first fatal
exception.
Change the NSException handler generated from the Objective-C exception
preprocessor to not used the cached intermediate dump writer and
not use the same first-exception-wins logic. This is useful because the
Objective-C exception preprocessor is imperfect and may generate
intermediate dumps that are not followed by process termination.
Simplify DumpWithoutCrashing's ownership of its intermediate dump writer
to be thread safe.
Set a handler for SIGPIPE for applications that haven't already
ignored or set a handler for SIGPIPE.
Bug: crashpad:391
Change-Id: Ia8ae61d50be81910fa0af40325300441d9dc01b6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3401563
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
The badAccess test may return different mach exception codes depending
on optimization levels. Simplify by this by turning off optimization
for this particular test.
Also removes testSegv, which was duplicative and not really testing
SIGSEGV.
Change-Id: Idb92731da6a86545ed83c2bbdd200a0b792c579f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3403040
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Right now there's no clear way to differentiate between Signal and Mach
exceptions. Instead, set EXC_SOFT_SIGNAL as the top level exception for
signal exceptions, moving the signal number to ExceptionInfo() and
and the signal code plus the two previous values into Codes().
Fixed:crashpad:389
Change-Id: Ia57f402b98be2a648febb58b9dee0cb80d9e5954
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3388874
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Another set of iOS redacted sinkholes appear in CoreAutoLayout.
However, this is often called by our code, so it's unsafe to simply
handle an uncaught nsexception here. Instead, skip the frame and
continue searching for either a handler that belongs to us, or another
sinkhole.
Bug: crashpad: 31
Change-Id: I20be2acef96f5ee6b7521144548e920e635f0dc7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3261270
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The iOS crashpad client was mistakenly setting the process annotations
(typically things like version and product name) when converting the
intermediate dump into a minidump. This is incorrect, as those
annotations are determined at intermediate dump creation time.
Instead, correctly write those annotations during intermediate dump
creation. Passing extra annotations during intermediate dump to
minidump is still supported.
Bug: crashpad: 31
Change-Id: Ic5e29debdc123011d130f75a48345071575466d9
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3266127
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
When code raises an Objective-C exception, unwind the stack looking for
any exception handlers. If an exception handler is encountered, test to
see if it is a function known to be a catch-and-rethrow 'sinkhole'
exception handler. Various routines in UIKit and elsewhere do this, and
they obscure the exception stack, since the original throw location is
no longer present on the stack (just the re-throw) when Crashpad
captures the crash report. In the case of sinkholes, trigger an
immediate exception to capture the original stack.
The is an improvement over the alternative,
NSSetUncaughtExceptionHandler, which passes along the stack frames, but
not the stack memory contents and full exception context itself.
The details of what happens after a fatal exception is triggered are
unresolved in this CL. For now, simply call std::terminate.
This code was inspired by chromium/src/chrome/browser/mac/
exception_processor.mm.
Bug: crashpad:31
Change-Id: Ieebc6476a0507c466c8219c10f790ec0a624e58c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2125254
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
First steps at bringing up the crashpad_client on iOS. Also updates
the XCUITest to trigger various crashes, with some swizzling
necessary to allow crashes.
Change-Id: I87dd36bed1c052b509d14bfa29679ed81e58a377
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2039470
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
