This attempts to be somewhat forward-compatible with upcoming additions
to the Data struct, most importantly to not lose the client ID if we
ever need to downgrade / read data from a future crashpad version.
Bug: 42310127
Change-Id: Ic3914fdd8460f4f41e5bb523d5c52361767880dd
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5915193
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Jesse McKenna <jessemckenna@google.com>
Commit-Queue: Peter Boström <pbos@chromium.org>
This was tested locally by adding "-Wunreachable-code-aggressive" after
making NOTREACHED() [[noreturn]] in mini_chromium and then getting that
to compile.
Bug: chromium:40580068
Change-Id: I7ec1c72be1d73436d128660a621e9060eaebaee8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5780891
Reviewed-by: Mark Mentovai <mark@chromium.org>
This was generated by replacing " NOTREACHED()" with
" NOTREACHED_IN_MIGRATION()" and running git cl format.
This prepares for making NOTREACHED() [[noreturn]] alongside
NotReachedIsFatal migration of existing inventory.
Bug: chromium:40580068
Change-Id: Idb68e2fc8adba180350b0595fd494cf0f206bded
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5548246
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
The memory region data saved in the intermediate dump is an address
offset by 128 bytes. However, the MemorySnapshot generated was using the
original address and not the offset address. The same data is being
captured in the minidump.
Change-Id: Ia34912c035319e79cf446a130e662084f4ab51ea
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5529059
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
There were two issues with the iOS implementation of CrashpadClient
which I reported in https://crbug.com/crashpad/481:
1) TSAN found a data race in ResetForTesting() when it modified the
ScopedMachReceiveRight while the Mach exception port thread was
reading it
2) The Mach port connected to the exception server was never deallocated
This CL fixes both issues.
Change-Id: I5bd4f79ae6d0eccca954d663be7a36f8ceb0a0e8
Bug: https://crbug.com/crashpad/481
Bug: b:332305593
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5410301
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Previously, Crashpad would only capture iOS thread context memory regions by iterating the task_threads->thread_get_state's. For Mach
exception this worked as intended. However, for signal exceptions this
missed the registers from the actual signal context. This change
correctly captures these regions and stores them in the exception
snapshot.
Change-Id: I494e753a25c2687e61b5183ed0135f520ca8bf52
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5380505
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This CL make the iterators implemented by AnnotationList compliant to
the requirements imposed by the C++ standard on input iterators.
Change-Id: I263c94a97f5bcd7edd5ef4d8b65fa28b11876974
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5093147
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
There appears to be a change in dyld in macOS 14.3 that iOS 17
accounts for, but older simulators do not. This causes the main
binary to be listed twice when iterating modules, breaking some
tests.
Bug: crbug.com/328282286
Change-Id: I71909fbc13bee6de23b10ffd92a791067f8ea909
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5353754
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This change adds a method to update a CrashpadInfo stream.
As part of this change, AddUserDataMinidumpStream() now returns a handle
to the added stream. This handle can be passed to
UpdateUserDataMinidumpStream() if a new version of the stream needs to
be attached to the crash report.
This method is needed for e.g., allowing Chrome's System Profile to
update, as it contains some data that takes a while to collect.
Bug: crashpad:474
Change-Id: I19e935a6904d8843215582e5606b189479ee338b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5260024
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Jesse McKenna <jessemckenna@google.com>
The change in macOS 14's dyld to insert new modules in the front of
`dyld_all_image_infos` means that if the any images are loaded
during an exception while iterating the modules list, the primary
executable will be missed. Instead, read the modules in reverse
order.
Change-Id: I49f6468173f18ef4bd0f326c84e4b48cfc696cd3
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5249275
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This CL introduces a new crash key 'crashpad_uptime_ns' that records the
number of nanoseconds between when Crashpad was initialized and when a
snapshot is generated.
Crashpad minidumps record the MDRawMiscInfo process_create_time using a
sysctl(KERN_PROC).kp_proc.p_starttime. This time is used to display the
'uptime' of a process. However, iOS 15 and later has a feature that
'prewarms' the app to reduce the amount of time the user waits before
the app is usable. This mean crashes that may happen immediately on
startup would appear to happen minutes or hours after process creation
time.
While initial implementations of prewarming would include some parts of
main, since iOS16 prewarming is complete before main, and therefore
before Crashpad is typically initialized.
Bug: crashpad:472
Change-Id: Iff960e37ae40121bd5927d319a2767d1cafce846
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5171091
Reviewed-by: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
The real Chromium base/bit_cast.h is in the base namespace.
mini_chromium's version was just changed to be in the base namespace
as well. Roll to the latest mini_chromium and scope all calls to
bit_cast.
Bug: chromium:1506769
Change-Id: I7b25ee512f67694ef6ed3d0250e4f6a6db151eb3
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5116880
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
bit_cast should never be used on pointers, as it doesn't avoid UB and
can lose qualifiers.
Fortunately, the only use of bit_cast on a pointer was to cast
nullptr into a function pointer, and because nullptr will implicitly
behave as any kind of pointer, that cast isn't needed.
Bug: none
Change-Id: I3ad79b36b7fb5ab53d4b4b6dfc82dea883ec8b53
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5106728
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
This CL implements a const iterator to allow for iteration over a const
AnnotationList. This way, the annotation list can passed as a const
reference in search only situations.
Change-Id: I53bd7871f3d914e7e7e627b6b464aa7fa79597f4
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4984053
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Andre Kempe <andre.kempe@arm.com>
memcpy and memchr on NULL, 0 is UB due to a C language bug. Instead, use
the C++ functions, which do not have this bug.
Bug: chromium:1394755
Change-Id: I82023aa038c53905f9867c635b26f3b26d9994f5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4987148
Commit-Queue: David Benjamin <davidben@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This reverts commit e17518a9e879f63b578db6c184c6bb17f1b13a06.
Reason for revert:
When trying to roll Crashpad into Chromium, all the new tests in
this CL fail; https://crrev.com/c/4984643?checksRunsSelected=win-rel&tab=checks
Original change's description:
> Add an option to start a Windows client with global hooks disabled.
>
> Change-Id: I645d6136788ca4ccebfc73005c8c2455dc4b2cee
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4949671
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Rich Mckeever <mckeever@google.com>
Change-Id: I3a41238cf0960899fac19d1e6d0ed0e527dfe13f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4985124
Reviewed-by: Mark Mentovai <mark@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Avi Drissman <avi@chromium.org>
Fixes a pending issue when we eventually move to C++20.
Original author: Dean Sturtevant
Change-Id: I7bb0648c73df6b6a28a3a4debdb4524d3cd27b38
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4979733
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Eric Astor <epastor@google.com>
Include check_op.h directly, instead of relying on the transitive
include from logging.h. This transitive include does not exist in
Chromium's //base.
Change-Id: I15962a9cdc26ac206032157b8d2659cf263ad695
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4950200
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
f145b54e8378c8e2bd1fbb427684ca9b4c54ea9c put the only reference to this
in a non-ASAN block, so we're hitting an unused function warning rolling
into Chromium
Bug: crashpad:464
Change-Id: I225debd48a255aa5214e02a6821dcd72c618f141
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4939552
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
ASAN injects a bad de-reference in HandleHeapCorruption() that causes it to be recursively invoked.
Bug: crashpad:464
Change-Id: I5e8db5555462166b963e0e43c6eb8ac0b327219e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4935953
Reviewed-by: Alex Gough <ajgo@chromium.org>
Commit-Queue: Rich Mckeever <mckeever@google.com>
Some users of crashpad load and unload the dll that hosts
crashpad code. crashpad registers a vectored exception handler
to help collect heap corruption crashes. If the dll is
unloaded this handler might still be called.
This CL adds a scoped handler for such registrations and
uses it on Windows crashpad client. To allow this to
be stored, RegisterHandler() on the client needs to move
onto the client object from being a helper function.
Bug: crashpad:462
Change-Id: I5d77c056e2a9a61ddcfa9d0186ab4bfd85a19bff
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4898263
Reviewed-by: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
This is a reland of commit b1e66e322ddd07f4640ee8bad93397a0511cd313
Original change's description:
> Add SetLastChanceExceptionHandler to implement permissive MTE mode
>
> SetLastChanceExceptionHandler sets a callback to be called after a
> crash has been reported. Returning true from this callback will
> not reraise the signal so the execution can continue. This will be
> used to implement permissive MTE mode, which will continue execution
> after a MTE crash.
>
> Bug: chromium:1467915
> Change-Id: I93a28ceea921fe977805482cf47c07643ca6133c
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4707688
> Reviewed-by: Robert Sesek <rsesek@chromium.org>
> Commit-Queue: Keishi Hattori <keishi@chromium.org>
Bug: chromium:1467915
Change-Id: Ibdc18084deb08bccf3c74f688b7d48ff24fe81f9
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4756235
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Keishi Hattori <keishi@chromium.org>
This CL rolls mini_chromium to pick up the move of a bunch of files
to base/apple, and makes changes to adjust.
Bug: chromium:1444927
Change-Id: Ib692e2a1628e2c0c8228795eaecdb7f35b1c09fa
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4786387
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
ARC is now enabled by default, so there’s no need to enforce it
against files being put into non-ARC targets.
Bug: chromium:1468376
Change-Id: I58bbb4d1736293a6e9977954ce932dcfe2bafa54
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4750419
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This reverts commit b1e66e322ddd07f4640ee8bad93397a0511cd313.
Reason for revert: test was flaky on Android bot
Original change's description:
> Add SetLastChanceExceptionHandler to implement permissive MTE mode
>
> SetLastChanceExceptionHandler sets a callback to be called after a
> crash has been reported. Returning true from this callback will
> not reraise the signal so the execution can continue. This will be
> used to implement permissive MTE mode, which will continue execution
> after a MTE crash.
>
> Bug: chromium:1467915
> Change-Id: I93a28ceea921fe977805482cf47c07643ca6133c
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4707688
> Reviewed-by: Robert Sesek <rsesek@chromium.org>
> Commit-Queue: Keishi Hattori <keishi@chromium.org>
Bug: chromium:1467915
Change-Id: Id815a780b576088974101117a4587adec64cfe8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4750459
Commit-Queue: Keishi Hattori <keishi@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
SetLastChanceExceptionHandler sets a callback to be called after a
crash has been reported. Returning true from this callback will
not reraise the signal so the execution can continue. This will be
used to implement permissive MTE mode, which will continue execution
after a MTE crash.
Bug: chromium:1467915
Change-Id: I93a28ceea921fe977805482cf47c07643ca6133c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4707688
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Keishi Hattori <keishi@chromium.org>
CaptureContext isn't actually used on Fuchsia and there is a desire to
remove `ucontext_t` from Fuchsia as it isn't a real concept on Fuchsia
and was only added as a placeholder. Moreover, `ucontext_t` won't ever
be added to Fuchsia for RISC-V.
Bug: fuchsia:123052
Fixed: fuchsia:131112
Fixed: fuchsia:127655
Tested: `fx test crashpad` on core.x64 emulator
Tested: `fx test crashpad` on ARM64 device
Tested: `fx shell crasher` @ 16b19a9891978487 on ARM64 device, ran
through Breakpad stackwalker locally as well
Tested: `fx build crashpad_tests` for minimal.riscv64
Change-Id: I4695054426df78a9deff8c9ea9c478b5bf9701b1
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4717085
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Thomas Gales <tgales@google.com>
Windows claims that heap corruption crashes are passed
to Windows Error Reporting but they are not, they are
swallowed and the process is simply terminated. WerFault.exe
does not run.
We can however intercept these crashes using a vectored
exception handler which forwards STATUS_HEAP_CORRUPTION
to the normal crash handler.
Adds an end-to-end test.
Bug: 2515
Change-Id: I2e1361dacef6fd03ea0f00327fee0b05a0c4899e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4637533
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Remove the reference to `base/cxx17_backports.h` from the code.
Bug: chromium:1373621
Change-Id: I84dd5fc1b069b168e4558316344c1f1c5377a68b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4471860
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
In the recent llvm upstream change, https://reviews.llvm.org/D148269,
clang becomes smarter and will remove the infinite recursion function.
Use the clang attribute __attribute__((optnone)) to disable optimization
for it.
Bug: chromium:1435016
Change-Id: I74e823bf64d0b03d81c0bda7a8338e2fa67033aa
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4456156
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Zequan Wu <zequanwu@google.com>
ObjcExceptionPreprocessor is a 'reasonable effort' attempt to catch an
NSException minidump at time the exception is thrown as opposed to when the application terminates due to the exception. If multiple
exceptions are thrown at the same time, Crashpad should correctly
report the final uncaught exception, but the minidump may not
represent the full `caught-at-thrown` minidump.
- Don't assume ObjcExceptionPreprocessor throws an NSException.
- Don't retain/release the exception. Instead of calling isEqual,
just use a simple pointer comparison.
- Make last_exception atomic.
Bug: crashpad: 445, 446
Change-Id: I9f2f2041e96aa9818c63937025e507487ae9d03d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4317110
Reviewed-by: Ben Hamilton <benhamilton@google.com>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
StringToInt(string_piece) works because base::StringPiece is in
namespace base, but when it is switched to std::string_view, this won't
work anymore. Use the idiomatic spelling.
Bug: chromium:691162
Change-Id: Ic45e0d2729fa5fc7c3e7a56fe159957b1bdcdf94
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4298113
Commit-Queue: David Benjamin <davidben@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The test BaseAnnotationShouldNotSupportSpinGuard assumed NDEBUG builds
always disabled DCHECK()s, but DCHECK_ALWAYS_ON overrides this.
This CL fixes the test for NDEDBUG + DCHECK_ALWAYS_ON builds by using
the DCHECK_IS_ON() macro to skip the test when DCHECKs are enabled.
Change-Id: I7b64729568c5d3139ca777e27462d81eba931834
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4255429
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Since iOS reads Annotations in-process, this CL updates the iOS
intermediate dump handler to check each Annotation to see if it supports
guarding concurrent reads and writes using ScopedSpinGuard.
For any such Annotation, the in-process dump handler now tries (without
spinning) to obtain the ScopedSpinGuard for the Annotation before
reading its memory.
If the ScopedSpinGuard cannot immediately be obtained, the in-process
dump handler just skips writing the memory of the Annotation to the
intermediate dump. (I'd like to follow up and thread down a Params
object so we can experiment with adding an optional timeout to make
this more reliable.)
Change-Id: Ie6c9849fac94ab89b36364b07aea62326cabe552
Bug: crashpad:437
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4031730
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This CL integrates the new ScopedSpinGuard with the new
LengthDelimitedRingBuffer into a new class, RingBufferAnnotation.
RingBufferAnnotation is thread-safe both for reading and writing, and is
suitable for streaming logs, trace events, and other high-throughput
data streams.
I included a load test (ring_buffer_annotation_load_test) which launches
two threads which simultaneously write to and read from the
RingBufferAnnotation.
By default, reads and writes are serialized using ScopedSpinGuard, but
passing the flag "--disable_spin_guard" to the test disables the spin
guard on the reading side (which is expected to make the test fail).
Change-Id: Ic8e28866d085d57e778c4f86bcb7492ef0638ab9
Bug: crashpad:437
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4023619
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
This CL optionally integrates ScopedSpinGuard (an atomic boolean) with
crashpad::Annotation.
Subclasses of Annotation can choose to integrate ScopedSpinGuard into
their Set(...) methods to ensure reads and writes are serialized.
I didn't integrate this into StringAnnotation in this CL, but it'd be
pretty trivial to do in a follow-up.
Change-Id: I1c5b8982576b03f9780a57acb7627c9194f8f0ff
Bug: crashpad:437
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4022484
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This CL cleans up types and code style comments from post-submit code
review comments on https://crrev.com/c/4023618 .
I also added fixes for potential overflows in varint length decoding
and included new tests.
Bug: crashpad:437
Change-Id: I0a3585036028d81f42d0d36e87cce4264f4ed9ad
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4199705
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
ARM64 supports storing pointer authentication codes in the upper bits of
a pointer. This mask can be used by LLDB to mimic ptrauth_strip and
strip the pointer authentication codes. To recover an address from
pointer with an authentication code, `AND` this mask with the pointer.
If the platform does not support pointer authentication, or the range of
valid addressees for a pointer was unaccessible, this field will be 0
and should be ignored.
Change-Id: Ie5cef90802dd1e892d456195ab8874223eac6a1b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2773358
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This CL implements LengthDelimitedRingBuffer, a general-purpose
ringbuffer suitable for use as a Crashpad Annotation.
This ringbuffer supports writing variably-sized data delimited by a Base
128 varint-encoded length separator.
LengthDelimitedRingBuffer is backed by a std::array, so it has a fixed
maximum size. It supports reading via RingBufferReader as well as
writing via RingBufferWriter.
Change-Id: I23ecb4a85ee8e846e1efc6937a5cb089a494d50a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4023618
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
This is necessary to roll Crashpad in Chromium. Fixes the following:
[5984/6587] CXX obj/third_party/crashpad/crashpad/client/client_test/crashpad_client_linux_test.o
FAILED: obj/third_party/crashpad/crashpad/client/client_test/crashpad_client_linux_test.o
python3 ../../build/toolchain/clang_code_coverage_wrapper.py --target-os=linux --files-to-instrument...(too long)
../../third_party/crashpad/crashpad/client/crashpad_client_linux_test.cc:522:20: error: code will never be executed [-Werror,-Wunreachable-code]
struct utsname uname_info;
^~~~~~~~~~
1 error generated.
Bug: chromium:1260217
Change-Id: Ie63881ed82faec84e8d45bb30dfc8ef10cfdbd6d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4028794
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
SA_EXPOSE_TAGBITS is a Linux >= 5.11 feature that allows si_addr to
contain the upper tag bits. This is a feature that allows signal
handlers to see the full upper address bits on aarch64, which consist of
TBI and MTE nibbles. For MTE, preserving these bits is of significant
importance, as it allows for precise use-after-free and buffer-overflow
diagnosis that's impossible without seeing these bits in the fault
address.
We unconditionally enable this feature on all kernels, as it's ignored
when unsupported (even on older kernels).
Tested on:
1. Linux x86 host, which is a no-op.
2. Android device with Linux 4.14, which is a no-op.
3. Android device with Linux 5.15, which passes. For posterity, my
config was:
| $ gn args out_arm64
| target_os = "android"
| android_ndk_root = "~/Android.sdk/ndk/21.4.7075529"
| android_api_level = 26
| target_cpu = "arm64"
| # NDK builds push libc++_shared.so, which is not present on newer Android
| # versions, so I hacked the runner to push the file. Maybe this should be
| # upstreamed at some point as well.
| $ git diff
| diff --git a/build/run_tests.py b/build/run_tests.py
| index 8ad19e34..64269c90 100755
| --- a/build/run_tests.py
| +++ b/build/run_tests.py
| @@ -273,7 +273,8 @@ def _RunOnAndroidTarget(binary_dir, test, android_device, extra_command_line):
| _adb_shell(adb_mkdir_command)
|
| # Push the test binary and any other build output to the device.
| - local_test_build_artifacts = []
| + local_test_build_artifacts = [
| + '~/Android.sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/aarch64-linux-android/libc++_shared.so']
| for artifact in test_build_artifacts:
| local_test_build_artifacts.append(os.path.join(
| binary_dir, artifact))
| @@ -294,6 +295,7 @@ def _RunOnAndroidTarget(binary_dir, test, android_device, extra_command_line):
| # The list of TERM values comes from Google Test’s
| # googletest/src/gtest.cc testing::internal::ShouldUseColor().
| env = {'CRASHPAD_TEST_DATA_ROOT': device_temp_dir}
| + env = {'LD_LIBRARY_PATH': device_out_dir}
| gtest_color = os.environ.get('GTEST_COLOR')
| if gtest_color in ('auto', None):
| if (sys.stdout.isatty() and
| $ ninja -C out_arm64 && python build/run_tests.py out_arm64/ \
| --gtest_filter=*StartHandlerForSelfTestSuite*
Change-Id: I293b36fcd08ffaca593dae8042299a39756defa0
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4024204
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mitch Phillips <mitchp@google.com>
On gLinux, tests don't pass in the default configuration (empty GN
args), because the infinite recursion test doesn't crash
anymore. Locally, forcing the function to stay out of line is sufficient
to fix it. This is inherently brittle, and may need to be revisited at a
later point.
Change-Id: Ica88a0b3a2151af95c64c490b5afcdc05cf3be4e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4020321
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Fixes NOTREACHED not being available in client/settings.cc. This was
available when compiling Crashpad standalone, but not as part of
Chromium.
Bug: chromium:1358240
Change-Id: Ie61d3beabf9ab953369f8fd25556d6a602c0c043
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4009734
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Copy of crrev.com/c/3952963.
Fixes locking not working on some Android filesystems due to flock not
being available. Instead, we now use the same approach as Fuchsia with
a dedicated lock file. This is an issue when running tests on
non-rooted Android devices, as we need files to be written to a
location accessible without root, but the chosen location might not
have flock support.
Bug: chromium:1358240
Change-Id: Ie910481be472403a8b0e9e36100594b0618f85e6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3999273
Commit-Queue: Brian Sheedy <bsheedy@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Previously, StartProcessingPendingReports() only started the prune and
upload threads if it thought the application was actively running in
the foreground.
However, some Crashpad clients would like to replicate Breakpad's
behavior of allowing uploads while the application is starting up
(before it moves to the foreground).
This CL introdues an optional UploadBehavior enum to
InProcessHandler::StartProcessingPendingReports(), defaulting to the
current behavior of only uploading processed crash reports while the
application is in the foreground.
If the enum is set to UploadBehavior::kUploadImmediately, then
InProcessHandler will start the prune and upload threads regardless
of the application state. (If the application state later transitions
to a non-active state, then InProcessHandler will stop the prune and
upload threads as normal.)
Change-Id: I4f13f3a3006d636dd3e511b21ccc23a90b2ea639
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3894230
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
handler_sock end of the socketpair is donated to the crashpad server
process which owns it. The client should not keep it open. Otherwise
if the crashpad server process crashes and the client is reading from
client_sock, the client will hang forever because the other end is still
open.
This happens when:
- /proc/sys/kernel/yama/ptrace_scope file is present.
- crashpad is invoked with missing required fields, like --database.
In this case, chrome hangs until timeout.
Change-Id: I1776432d6d9fd44dc1c24e874a15fd6d2a376003
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3786896
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Ayush Ranjan <ayushranjan@google.com>
Adds a 4K buffer to the intermediate dump writer. Aside from the final
flush, only write in multiples of 4K. This saves between 30ms and 50ms
on an iPhone 12 Pro.
Change-Id: Icc4b222477bd91fd6952c7cf43b105e1f7a50adb
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3764243
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Rather than vm_reading each individual module load_command, load all of
the commands at once. This saves nearly 200ms on an iPhone 12 Pro.
Change-Id: I06f56c3ecbdf74f78759648ea62bcccd027f304c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3764242
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
On iOS, holding a lock during a slow upload can lead to watchdog kills
if the app is suspended mid-upload. Instead, if the client can obtain
the lock, the database sets a lock-time file attribute and releases the
flock. The file attribute is cleared when the upload is completed. The
lock-time attribute can be used to prevent file access from other
processes, or to discard reports that likely were terminated mid-upload.
Bug:chromium:1342051
Change-Id: Ib878f6ade8eae467ee39acb52288296759c84582
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3739019
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Adds a new IOSIntermediateDumpWriter::AddPropertyCString method which
takes an address to a cstring of unknown length and page-by-page
searches for a NUL-byte terminator.
This is necessary because currently WriteModuleInfo calls strlen
directly on the dyld and module filePath without first using vm_read.
On iOS14 this occasionally crashes, and is generally unwise. Instead,
use AddPropertyCString.
This patch also removes WriteDyldErrorStringAnnotation, as it's no
longer used going forward with iOS 15.
Bug: 1332862
Change-Id: I3801693bc39259a0127e5175dccf286a1cd97ba7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3689516
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This adds a runtime exception helper (& test module) for Windows and
plumbing to allow the module to be registered by the crashpad client,
and to trigger the crashpad handler. Embedders can build their own
module to control which exceptions are passed to the handler.
See: go/chrome-windows-runtime-exception-helper for motivation.
When registered (which is the responsibility of the embedding
application), the helper is loaded by WerFault.exe when Windows
Error Reporting receives crashes that are not caught by crashpad's
normal handlers - for instance a control-flow violation when a
module is compiled with /guard:cf.
Registration:
The embedder must arrange for the full path to the helper to
be added in the appropriate Windows Error Reporting\
RuntimeExceptionHelperModules registry key.
Once an embedder's crashpad client is connected to a crashpad
handler (e.g. through SetIpcPipeName()) the embedder calls
RegisterWerModule. Internally, this registration includes handles
used to trigger the crashpad handler, an area reserved to hold an
exception and context, and structures needed by the crashpad handler.
Following a crash:
WerFault.exe handles the crash then validates and loads the helper
module. WER hands the helper module a handle to the crashing target
process and copies of the exception and context for the faulting thread.
The helper then copies out the client's registration data and
duplicates handles to the crashpad handler, then fills back the various structures in the paused client that the crashpad handler will need.
The helper then signals the crashpad handler, which collects a dump then
notifies the helper that it is done.
Support:
WerRegisterExceptionHelperModule has been availble since at least
Windows 7 but WerFault would not pass on the exceptions that crashpad
could not already handle. This changed in Windows 10 20H1 (19041),
which supports HKCU and HKLM registrations, and passes in more types of
crashes. It is harmless to register the module for earlier versions
of Windows as it simply won't be loaded by WerFault.exe.
Tests:
snapshot/win/end_to_end_test.py has been refactored slightly to
group crash generation and output validation in main() by breaking
up RunTests into smaller functions.
As the module works by being loaded in WerFault.exe it is tested
in end_to_end_test.py.
Bug: crashpad:133, 866033, 865632
Change-Id: Id668bd15a510a24c79753e1bb03e9456f41a9780
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3677284
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
This is a reland of 460943dd9a71dc76f68182a8ede766d5543e5341
Original change's description:
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
The reland isolates the change to non-Android POSIX systems because
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
Change-Id: If44629f5445bb0e3d0a1d3698b85f047d1cbf04f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3721655
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This reverts commit 460943dd9a71dc76f68182a8ede766d5543e5341.
Reason for revert: This fails to compile in Chromium Android.
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
https://ci.chromium.org/ui/p/chromium/builders/try/android_compile_dbg/1179765/overview
Original change's description:
> posix: Replace DoubleForkAndExec() with ForkAndSpawn()
>
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
>
> Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Mark Mentovai <mark@chromium.org>
Change-Id: I7f6161bc4734c50308438cdde1e193023ee9bfb8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3719439
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This fixes a test case that accesses settings for the first time in
multiple threads simultaneously.
Fixed: crashpad:417
Change-Id: I6539682f171563f8ff5a1203fdd550ab92afc276
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3711807
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The DoubleForkAndExec() function was taking over 622 milliseconds to run
on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
some custom traces and found that the fork() syscall is the bottleneck
here, i.e., the first fork() takes around 359 milliseconds and the
nested fork() takes around 263 milliseconds. Replacing the nested fork()
and exec() with posix_spawn() reduces the time consumption to 257
milliseconds!
See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
slow on macOS and why posix_spawn() is a better replacement.
Another point to note is that even base::LaunchProcess() from Chromium
calls posix_spawnp() on macOS -
8f8d82dea0:base/process/launch_mac.cc;l=295-296
Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This CL adds a new method ThreadSnapshot::ThreadName(), implements
it in each snapshot implementation, and adds tests for iOS, macOS,
Linux, Windows, and Fuchsia.
Bug: crashpad:327
Change-Id: I35031975223854c19d977e057dd026a40d33fd41
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3671776
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Ben Hamilton <benhamilton@google.com>
Fuchsia's Crashpad roller was failing due to 'std::size' not being found
and struct fields not being initialized (detected by
-Wmissing-field-initializers)
- Fix 'std::size' issue by using a std::array instead of a plain C array
- Fix missing initializers with default values
Bug: fxbug.dev/101498
Change-Id: I75fa54d5c1730772b1af1be31c64b0cc58886a90
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3687239
Commit-Queue: Alex Pankhurst <pankhurst@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
There were two shutdown races in the iOS Crashpad client:
1) MachMessageServer::Run can return either MACH_RCV_PORT_CHANGED *or*
MACH_RCV_INVALID_NAME based on the timing of when the port is
closed, for example:
c21f7bab5c/Sources/CwlPreconditionTesting/CwlCatchBadInstruction.swift (L131)
2) The iOS crashpad::CrashHandler thread could read from its member
variable mach_handler_running_ while another thread wrote to it
Change-Id: I696ece8575d9b88cbd0593e7c479bd4c7f863f45
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3651395
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
* ATOMIC_FLAG_INIT is deprecated.
* Compound ops on volatiles are deprecated.
Bug: chromium:1284275
Change-Id: I2235662c00e4be8c5eba2aaf565663faf8d9576a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3658639
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Crashpad annotation names are currently limited to 64 bytes.
Breakpad supports up to 256 bytes, so for compatibility with existing
clients, this increases the maximum annotation name size from 64 to
256 and adds new tests to confirm the maximum name and value sizes.
Change-Id: Ib7954bea96046b6b7e18ed9743fe2a15dd3dabac
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3655975
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
IOSIntermediateDumpWriter::Close() is intended to close the FD opened
by the in-process handler.
Currently, InProcessHandler::ScopedLockedWriter::~ScopedLockedWriter() does invoke IOSIntermediateDumpWriter::Close().
However, InProcessHandler::Initialize() invokes the utility CreateWriterWithPath() which directly creates an IOSIntermediateDumpWriter. It neither uses ScopedLockedWriter nor invokes Close().
This fixes the issue by:
1) Making IOSIntermediateDumpWriter::~IOSIntermediateDumpWriter() DCHECK() that it's closed
2) Calling IOSIntermediateDumpWriter::Close() from InProcessHandler::~InProcessHandler() and from test files
Change-Id: Ibfede0a3d2aeac948c7ff3d56445e13d1a4028b5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3648710
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
It seems on iOS 14, sometimes this path can be empty. Passing nullptr
to strlen will crash. Also fixes an incorrect file path length for
the dyldPath.
Bug: 1323905
Change-Id: Idf1ef9e0165853a5d57d272896a40bf0b30a3368
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3637717
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This brings Crashpad in line with what Breakpad captures.
Change-Id: I8ce2d81fc9cb150dc9817034fac3516f27f5661b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3611069
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
It is not safe to start the upload thread when in the background (due
to the potential for flocked files in shared containers).
Bug: 1317812
Change-Id: Ie476c2ccbc7232bc9e1a30a7a497128a4248c39e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3595621
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Followup to crrev.com/c/3573184, which did not honor destructor order,
leading to the background task releasing before the lock.
Bug: 1313555
Change-Id: Ifbd3902964552458b83cfc550f50058067021499
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3591012
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
In a later CL, in some cases these structs were not zero-initialized
which caused some iOS tests to fail.
We now zero-initialize these structs which should be harmless now,
and useful later.
Bug: 1250098
Change-Id: I933e80e56714a1d8988deae3aa56ec36ed98ef03
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3538665
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Because the upload thread uses synchronous upload, calling Stop() on
that thread from the main thread will lock, and trigger a terminate
when transitioning from foreground to background.
Additionally, background assertions now only last 30 seconds, so
shorten the timeout to 20 seconds.
This is a followup to https://crrev.com/c/3517967.
Bug: crashpad:1315441
Change-Id: Ic6886607805667ffce5ecf41716fc63333a341b8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3577820
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Use ScopedBackgroundTask to prevent file lock termination from happening
when holding locked files in a shared AppGroup.
Bug: 1313555
Change-Id: Idc0105f8ecdb65c26214a7265a216b9d480ed01d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3573184
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Change the ObjExceptionProcessor to write intermediate dumps to a
temporary location until they are confirmed by the
UncaughtExceptionHandler. Because the exception preprocessor uses
heuristics to detect iOS sinkholes, it's possible for an exception to
be identified as fatal, but not actual trigger the uncaught exception
handler. If the processor detects more than one fatal exception, it will
unregister itself and indicate this in the second dump with the key
'MultipleHandledUncaughtNSException'.
This changes also consolidates and simplifies some methods in the
InProcessHandler.
Change-Id: Ifc457e974d25f533b77cfd18b702129fdfb10a75
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3529968
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Some sinkholes use objc_exception_throw instead of rethrow, which gives
the preprocessor a second, incorrect, attempt to process the
NSException. This also means if the processor misses the first sinkhole,
on the second attempt the original throwing stack will be missing.
Instead, track the original NSException and ignore any followup calls
to the ObjcExceptionPreprocessor with the same NSException.
Also creates a ExceptionPreprocessorState class to manage the complex
types. This will be used in a followup CL to finalize caught
NSExceptions using the uncaught handler.
Bug: 1300171
Change-Id: I1f9f2c7ee79c7a16585103f04831217979e9332b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3530246
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Stop the prune thread and the upload thread when moving to the
inactive/background state. This will reduce the number of 0xdead10cc
system kills from having a file lock during iOS suspend.
Wait to start the prune thread when the application is active.
Otherwise, for iOS prewarmed applications, the prune thread will
regularly start when the application is foregrounded for the first
time when the user intentionally runs the app.
It's still possible for either the prune thread or the upload thread to
have a file lock during iOS suspend, such as when a task started in the
foreground and does not complete in time for suspension. Future work
should include considering BackgroundTasks and/or NSURLSessions, which
can more safely run in the background.
Bug: crashpad: 400
Change-Id: Ic7d4687eb795fe585327f128aa84a5928141f4a9
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3517967
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
https://crrev.com/c/3401563 introduced logic to guard the cached
intermediate dump writer from concurrent exceptions with a first
exception wins approach. To prevent the losing exception from returning
immediately and terminating the app before the dump is written, the
losing thread sleeps indefinitely. In the case where the losing
exception is from a call to abort() and the winning exception is a Mach
exception, the process will never terminate because abort() will first
block all signals on all other threads with a sigprocmask. This prevents
the kernel from delivering the signal converted from the Mach exception
and will never terminate. This effectively deadlocks the app.
Instead, unblock all signals corresponding to all Mach exceptions
Crashpad registers for before returning KERN_FAILURE.
Bug: crashpad:391
Change-Id: I96c357e98f09e65e70c67125a45b9b04075c2c06
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3518186
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
in_process_intermediate_dump_handler_test was mixing CPU
architecture (x86_64 vs arm64) and iOS device type (iphoneos vs
iphonesimulator).
Bug: 1306589
Change-Id: Ie43a7f1916d69888e992320d999010071b2575b3
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3527034
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
iOS applications may be terminated with the exception code 0xdead10cc
when holding on to file locks in the shared container during suspension.
One approach to minimize this is to request additional background
execution time to complete the locking operation (in this case the
CrashReportUpload thread and the PruneIntermediateDumpsAndCrashReports
thread).
Bug: crashpad:400
Change-Id: I4192ae1a92646ea337a09ac071e49761ab2d3860
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3517966
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
The IOSSystemDataCollector was previously owned by the iOS CrashHandler
and passed in to the iOS InProcessHandler in each method. Move
ownership to iOS InProcessHandler to simplify.
Change-Id: Ifa41304cb1e3e3825a211e6cce5aa730d0edcc95
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3517965
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Override malloc_default_zone and malloc_default_purgeable_zone
with allocators that exit when called from the signal or Mach exception
threads in XCUITests, to verify the allocator is not used by the
InProcessHandler. Check stderr for error messages to confirm failures.
Change-Id: I1bb92e57504d71bbf6c6eaad3571c814e8a6934c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3488826
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
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>
Crashpad currently has a circular dependency: client->snapshot->client.
The dependency from snapshot -> client only exists to pull in a single
constant for Windows (CrashpadClient::kTriggeredExceptionCode), so this
change breaks the dependency by splitting the constant out into a new
file util/win/exception_codes.h.
Change-Id: I6b74b367df716e097758e63a44c53cb92ea5e04d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3450763
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
When trying to update Chromium's copy of crashpad I got this error
message:
Banned functions were used.
third_party\crashpad\crashpad\client\crashpad_client_ios_test.mm:33:
testing::Test should not be used in Objective-C++ code as it does
not drain the autorelease pool at the end of the test. Use
PlatformTest instead.
So, I'm fixing the code as requested.
The change was introduced in crrev.com/c/3418581
Change-Id: I4888febbd41b6365d9bde5ad062565770496243f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3459403
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
When updating Chromium's copy of crashpad I received this very
reasonable warning:
client\ios_handler\exception_processor.h: Includes STL header(s) but does not reference std::
So, this change removes the #include of vector.
Change-Id: I22f05b542fd4e0b582351072a3e3bb4af402b836
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3459402
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Bruce Dawson <brucedawson@chromium.org>
This patch adds optional support for Arm Pointer Authentication Codes.
X30/LR is not stored to stack at any place and restored for usage.
Therefore only adding PAC flag to .note.gnu.property section.
Change-Id: I9581059dfa1eed88af5a73df15b6a0d299caea13
Bug: crashpad: 1145581
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3440070
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org>
