Add Mach exception server and fill out exceptions snapshot.
Note that:
- The 'capture' portion of this CL will be moved out of the snapshot
interface and into a separate in-process dump to disk location.
- All of the pointer dereferences need to be wrapped in vm_read.
- The read-fast-and-dump logic in exception_snapshot will end up in a
different file completely, but until we pick a
serialization/deserialization method, keep it as-is.
Bug: crashpad:31
Change-Id: I44203aa44036a341d6b4517fde7ab0cb9d7e94d7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2160122
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This updates the way that the .defs files added in 1bfd7d06ed60 are
treated, by putting them in compat/ios, using compat as intended. The
.defs files in compat forward, via #include, to the ones in
third_party/xnu. Additionally, compat/mac is enabled for iOS, as
everything in compat/mac is sensible on iOS, and will have no effect
when rendered unnecessary by the iOS SDK.
This also changes util:mig_output to a static_library instead of a
source_set. I don’t think there was any reason for it to have been a
source_set to begin with. static_library is preferred for nearly
everything.
Bug: crashpad:31
Change-Id: I7c468d6d6785bf2bc825d45831ebb81e1c9ddfbc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2160310
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This makes UniversalMachExcServer available on iOS.
UniversalMachExcServer is the foundation for a Mach exc and mach_exc
server.
Some code in UniversalMachExcServer needs to be evaluated to ensure that
portions that run in the same process that has sustained the exception
are safe to do so at that time. For example,
SimplifiedExcServer<ExcTraits>::Interface instantiates and appends to a
std::vector<>, which is generally unsafe in this context. However, that
code responds to exc requests. The mach_exc equivalent,
SimplifiedMachExcServer<MachExcTraits>::Interface, does not use a vector
at all.
This also enables support code in the form of CompositeMachMessageServer
and UniversalExceptionRaise, all of the tests for
CompositeMachMessageServer, and most of the test for
exc_server_variants.cc. The multiprocess-based exc_server_variants tests
remain disabled on iOS.
Bug: crashpad:31
Change-Id: I838ed770a33ca29c37383c32245eb340fb3ad2fb
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2159287
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
mig was being invoked without any -arch argument, causing it to assume
the build system’s native architecture, which would be x86_64. This is
not correct for iOS device builds, which use arm64. The -arch argument
must be plumbed to mig for correct behavior.
When building for iOS, mig was being invoked without any -isysroot
argument, causing it to use the root for the build system, which runs
macOS and not iOS. The macOS SDK doesn’t include the ARM definitions
needed for iOS device builds.
<mach/exc.defs> and <mach/mach_exc.defs> depend on a small number of
other .defs files to provide definitions of standard types. All .defs
files are absent from the iOS SDK. These .defs files are borrowed from
xnu and placed in third_party/xnu. An additional --include argument is
added to allow mig to locate these files.
Bug: crashpad:31
Change-Id: I27154310352939ebe2fb6329bbbfda701c369289
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2159291
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This updates (and corrects) 8dbbaff2e1a5, which added exc.defs, by
adding mach_exc.defs too.
The difference betwen the exc and mach_exc subsystems is that the |code|
parameter is int[] in exc and int64_t[] in mach_exc. Many exceptions
carry the exception address in code[1], and a 32-bit int results in the
exception address being truncated in exc. No information is lost in
mach_exc, where a 64-bit int64_t is used.
In 8dbbaff2e1a5, I misremembered the type of the |code| parameter as a
type derived from uintptr_t, such as vm_address_t, an integer as wide as
a pointer. I was wrong, and mach_exc is necessary. I also noted that
Apple normally forbids mach_-prefixed interfaces in favor of the
prefix-less ones for the reasons I mentioned, and that, all else being
equal, it was desirable to adhere to the spirit of that convention.
Because neither exc nor mach_exc are available in the SDK, it’s moot
from a technical perspective, as we need to provide our own stubs either
way.
Bug: crashpad:31
Change-Id: Ied1be470e653b2bead1a283cb8b9283d210c328d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2159286
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This enables the following code in util/mach on iOS:
- exception_behaviors.{cc,h}
- exception_ports.{cc,h}
- mach_message.{cc,h}
- mach_message_server.{cc,h}
Only the ExceptionBehaviors and MachMessage tests are built, because the
other two are tested by multiprocess tests that won’t run on iOS.
The AuditPIDFromMachMessageTrailer function from mach_message.h is
excluded on iOS because it relies on <bsm/libbsm.h>, which is broken on
iOS: it depends on <bsm/audit_record.h>, which is missing from the SDK.
Additionally, the BSM function that Crashpad uses, audit_token_to_au32,
is marked as unavailable on iOS. Crashpad uses it on macOS to
authenticate Mach messages sent by other processes, but this is moot on
iOS.
Bug: crashpad:31
Change-Id: I5ebc4b80543989b9cd0b85b82eb4b3ff98c44e6c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2155086
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
The iOS SDK doesn’t include a copy of <mach/exc.defs>. It only provides
<mach/exc.h>, which is just the user-side header. To obtain declarations
and implementations of the server-side stubs, a current copy of
<mach/exc.defs> is added to third_party, and the mig action in util is
updated to use it on iOS.
The three other mig subsystems that Crashpad uses are not brought to
iOS:
- mach_exc is identical to exc except it always uses 64-bit quantities
for addresses in place of exc’s use of quantiies sized for native
pointers. Because all iOS work is limited to a single process, there
is no need to consider cross-process operation with variable bitness,
so mach_exc is unnecessary. We’re also only targeting 64-bit for iOS,
so exc will always suffice. This follows the spirit of other
mach_-prefixed routines on iOS, where Apple forbids mach_vm_read to
user applications but permits vm_read.
- notify is primarily used on macOS in the Crashpad handler process to
receive a no-senders notification, which is used to trigger handler
shutdown when it has no more clients. This is not believed to be
useful to Crashpad on iOS, which is restricted to single-process
operation.
- child_port is a Crashpad-specific subsystem used to pass Mach rights
between processes, but is similarly useless when restricted to
single-process operation as on iOS.
Bug: crashpad:31
Change-Id: Id4cb3cdd529814438d378c20702c82c1e89dd2be
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2154530
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
mach_extensions is sensible on iOS, but bootstrap is not available
outside of macOS. To allow mach_extensions to be used cleanly on iOS,
the bootstrap code is moved into its own macOS-specific file.
Bug: crashpad:31
Change-Id: I7bf9d5194253b563954a1e55fbf67a16f686e8ff
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2154529
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This builds some code in the util and test libraries on iOS that was
previously excluded. It also enables tests for this code, and other
tests that it was possible to enable either previously or as a result of
this change.
Previously, crashpad_util_test ran 178 tests from 46 test suites, and
crashpad_test_test ran 2 tests from 2 test suites. Now,
crashpad_util_test runs 284 tests from 62 test suites, and
crashpad_test_test runs 6 tests from 4 test suites.
The related .gn files also suffered through a slight cleanup.
Bug: crashpad:31
Change-Id: I84cdda5631f0ea4888ada902a8462776ac46fd2a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2154526
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: 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>
Bionic installs signal handlers which request crash
dumps from Android's debuggerd, but there are errors
in how signals which aren't automatically re-raised
are handled on Marshmallow (API 23).
Before requesting a dump, Bionic acquires a lock to
communicate with debuggerd and expecting imminent
death, never releases it.
While handling the dump request, debuggerd allows
the dying process to continue before
ptrace-detaching it. So, when Bionic manually
re-raises a signal, it is intercepted by debuggerd
and the dying process is allowed to live.
Bionic restores SIG_DFL for the signal it's just
handled, but if a different crash signal is later
recieved, Bionic attempts to reacquire the lock to
communicate with debuggerd and blocks forever.
Disable Bionic's signal handlers for these signals
on Marshmallow.
Bug: chromium:1050178
Change-Id: Ia1fc5a24161a95931684d092ba8fee2f0dfbbdbb
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2134513
Reviewed-by: Mark Mentovai <mark@chromium.org>
Gather most of the necessary information for the system snapshot.
Note that:
- The 'capture' portion of this CL will be moved out of the snapshot
interface and into a separate in-process dump to disk location.
- All of the pointer dereferences need to be wrapped in vm_read.
- The read-fast-and-dump logic in thread_snapshot may end up in a
different file completely, but until we pick a
serialization/deserialization method, keep it as-is.
Bug: crashpad:31
Change-Id: Iac82491fdb4a823163f02149f52a1e18e26fa9de
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2090173
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These should be the remaining instances of UB errors we see.
Bug: fuchsia:46805
Change-Id: Id8285386fd6cb52518f6076ddb79ac60025f9f87
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2067754
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
- Add option to log minidump in handler_main, also add option to
disable to dump minidump and generate report.
- Implement log minidump in CrashReportExceptionHandler.
Bug: crashpad:308
Change-Id: I8d2f7e118912011a8416f1ec36c9ee9d561d06e6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1995825
Commit-Queue: Tao Bai <michaelbai@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
- This tool could compress/encode or decode/decompress the minidump
log file, will be used by script to symbolize the crash.
- Added FileOutputStream and FileEncoder.
Bug: crashpad:308
Change-Id: I15c3e4908882a09983ec81a90e38249967c29fc4
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1968059
Commit-Queue: Tao Bai <michaelbai@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Emit the received data to Android logcat in Android, and noop for
other platforms.
Bug: crashpad:308
Change-Id: I6e46e2fa8bd61f93f614ad0bfb6441a79139b04b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1958711
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This CL adds code to check if the current thread holds the DLL loader
lock. This code can be used to enforce the requirement that certain
parts of crashpad, such as process creation are not done during calls
to DllMain which can lead to deadlocks and crashes. Only one check is
current enforced, in client process creation, and only in debug builds.
Bug: crashpad: 316
Change-Id: I5757a264bbf28ce2ab88a0cd7ac9481e46428c17
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1945993
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: James Forshaw <forshaw@chromium.org>
ProcStatReader.Threads is flaky because it relies on an internal,
imprecise measurement of boot time. The flaky test asserts that a
thread started after the main thread should have a start time >= the
main thread. The start time is returned in a timeval, with microsecond
precision, but the measurement of boot time requires two system calls
and the time between those system calls can be approximately a
microsecond. An unlucky event such as a change in system time could
make this imprecision arbitrarily bad.
This patch lets the caller of ProcStatReader.StartTime() inject the
boot time, allowing ProcStatReader to guarantee that threads have
correctly ordered time, given the same input boot time.
Bug: 1016765
Change-Id: I6e4a944a1d58c3916090bab6a4b99573e71a89fc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1891588
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Chromium requires build artifacts to be generated deterministically so
commit a long-lived (10 years) test certificate to the repository.
Change-Id: I7a6e2441f506196ca58fbbf757648fa0ac70bc9a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1872188
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This is the 1st patch for logging minidump in Android. it adds
OutputStream interface and zlib implementation for output pipline.
Bug: crashpad:308
Change-Id: I4738b8f223886049e6e259b9b25c00e5120156e5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1745355
Commit-Queue: Tao Bai <michaelbai@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The ProcessMemorySanitized implementation only allows reads to a given
process if it falls within a given whitelist of memory ranges. This
ensures that 'sanitized' snapshots only allow reading memory that was
explicitly allowed.
Bug: crashpad:263, chromium:973167
Change-Id: I72712d7ea3cabfd49cc91ffbe563cb349e6fcfdb
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1752593
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Most Crashpad builds use Microsoft's armasm64.exe macro assembler
for .asm source files. When building in Chromium, clang-cl is used
as the assembler instead. Since the two assemblers recognize different
assembly dialects, the same .asm file can't be used for each.
As a workaround, use a prebuilt .obj file when the Microsoft-dialect
assembler isn't available.
The obj file is generated from the capture_context_win_arm64.asm
by armasm64 macro assembler. If this asm file is modified,
the obj file needs to be updated.
Change-Id: Id5a4a949997a27b04815aeb79b2540d30a52d34c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1632749
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Removes the remaining references to the old port-based exception APIs in
favor of the new channel-based APIs.
Bug: fuchsia:ZX-4031
Test: runtests on emulator and device
Change-Id: Ieac5b66c2f676966d1018d771cab6c8635f12a8f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1700321
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Francois Rousseau <frousseau@google.com>
This patch also updates WorkerThread to execute DoWork() when
DoWorkNow() has been called, which is relevant when DoWorkNow() and
Stop() have both been called. This occurs regularly on Android where
the handler's current normal mode is to dump a single process and exit.
This change ensures the upload thread has a chance to upload the report
before the handler exits.
This change should not affect upload on Chrome/WebView/Chromecast which
don't pass Crashpad a --url option and are still responsible for their
own uploads.
Change-Id: Ie5553eafc13714f0438b4b133a92516f7abec153
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1643710
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, both the invocation to mig and mig's internal code would use xcrun
to locate binaries. When we're using the hermetic toolchain, we want to
explicitly specify the binaries to use and we want to avoid calls to xcrun.
Bug: chromium:971452
Change-Id: I8527368e0846bc72789e6454fcd626b028d297ff
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1650147
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
sendmsg() and recvmsg() are complicated to use. Refactor their usage
into functions with a simpler, tested interface and use those instead.
This also adds CreateCredentialSocketpair() to create a pair of
connected sockets with SO_PASSCRED set. This option should be set
before the possibility of any calls to sendmsg() with the socket pair
to avoid race conditions in properly setting credentials.
Also update the handler to use Strategy::kNoPtrace (which causes the
crash dump to fail without breaking the socket connection) if the
credentials were invalid, which can happen if SO_PASSCRED was set after
the call to sendmsg() or if the sending process does not exist in this
namespace.
Change-Id: Id09f87125540255687a3c35d5bed7fa01ec07cff
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1584639
Reviewed-by: Mark Mentovai <mark@chromium.org>
Multi client socket connections allow multiple clients to request crash
dumps from a handler process using a single, shared socket connection.
This connection mode does not support using a broker process which
requires a dedicated socket connection to ensure handler messages
aren't intercepted by the wrong clients.
The handler uses SIGCONT to indicate to the crasher when a crash dump
is complete (or has failed) and may continue.
Bug: crashpad:284
Change-Id: I2031029cd254f17497cbf7e7d8740c289581e8aa
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1559306
Reviewed-by: Mark Mentovai <mark@chromium.org>
now that we import fuchsia-sysinfo and fdio, this isn't really just zx anymore
Change-Id: Ic42359ce3d230e214ebdbbefb880ccb021434a0f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1555533
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
apple_cf is just a header, but we’ve got a BUILD.gn for
third_party/cpp-httplib, which is also just a header.
Change-Id: Ib42c25657b5964678d14682a0a802ebef0e4cb2f
Reviewed-on: https://chromium-review.googlesource.com/c/1489182
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Currently TaskMemory re-implements a number of Read* routines that are
implemented in a platform-independent way in ProcessMemory with access
to a single platform-specific ReadUpTo method. Implement the ReadUpTo
method for TaskMemory and subclass it from ProcessMemory to inherit the
remaining methods.
The ProcessMemoryTests didn't work on macOS because MultiprocessExec
can not access the child process' task port without root privileges or
the task_for_pid entitlement. Create an adaptor class for those tests to
use MachMultiprocess so that the child process sends its task port to
the parent.
Bug: crashpad:263
Change-Id: Id8e1788a74fe957f05703a5eb569ca3bf9870369
Reviewed-on: https://chromium-review.googlesource.com/c/1387265
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Currently, ProcessMemory is only implemented for Linux and Fuchsia.
Implement the interface for Windows as well and re-factor tests to
support it, mostly this consists of using a new ScopedGuardedPage class
instead of ScopedMmap in the ProcessMemory tests.
BUG=crashpad:262
Change-Id: I1b42718972be5ad838d12356d09f764053f09e4f
Reviewed-on: https://chromium-review.googlesource.com/c/1278829
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Some of the minidump functionality is going to be used in Fuchsia in
host side tools (in zxdb, the debugger). This fixes the Mac-host build
of util.
Change-Id: Ifeb3bd9c7fa29c99a272c97c2813b9c201ddfe88
Reviewed-on: https://chromium-review.googlesource.com/c/1277774
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This is a follow-up to e6f26587e435.
Bug: DX-382
Change-Id: I3116ea5dd2eca33961465d62c9200aa8dd1baf5d
Reviewed-on: https://chromium-review.googlesource.com/1173339
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
