On macOS 11, system libraries are no longer present on disk as
individual Mach-O files, but are shipped exclusively in the dyld shared
cache. This affects tests that verify the list of modules loaded into a
process. The new _dyld_shared_cache_contains_path function can be used
to determine whether a path exists in the dyld shared cache.
Bug: crashpad:347
Test: crashpad_snapshot_test ProcessReaderMac.{Self,Child}Modules
Change-Id: I19402e45701caeb850bdafd701ccbba4ef9c60bc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2384322
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This updates the process_types version of dyld_all_image_infos for macOS
11.0.
Test: crashpad_snapshot_test ProcessTypes.DyldImagesSelf
Bug: crashpad:347
Change-Id: Ieb134f17015070a11c918b26ece316f77a4cc263
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2384317
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The macOS 11.0 SDK, as of Xcode 12b6 12A8189n, has not updated
<AvailabilityMacros.h> with a MAC_OS_X_VERSION_11_0 or
MAC_OS_X_VERSION_10_16 constant. However, the <Availability.h> interface
has been updated to provide both __MAC_11_0 and __MAC_10_16.
<AvailabilityMacros.h>’s MAC_OS_X_VERSION_MAX_ALLOWED, which is supposed
to identify the SDK version, is broken in the 11.0 SDK in that whenever
the deployment target is set to 10.15 or earlier, the SDK will be
mis-identified through this interface as 10.15. When using the
<Availability.h> equivalent, __MAC_OS_X_VERSION_MAX_ALLOWED, the 11.0
SDK is identified as 10.16 (arguably it should be internally versioned
as 11.0, but at least this interface allows it to be detected
unambiguously.) It’s clear that the <AvailabilityMacros.h> interface
provides no meaningful support for the macOS 11.0 SDK at all, but
<Availability.h> does.
<Availability.h> was introduced in the Mac OS X 10.5 SDK, so there is no
relevant SDK version compatibility problem with this interface.
Key differences between these interfaces for the purposes used by
Crashpad:
- <AvailabilityMacros.h> → <Availability.h>
- MAC_OS_X_VERSION_MIN_REQUIRED (DT) → __MAC_OS_X_VERSION_MIN_REQUIRED
- MAC_OS_X_VERSION_MAX_ALLOWED (SDK) → __MAC_OS_X_VERSION_MAX_ALLOWED
- MAC_OS_X_VERSION_x_y → __MAC_x_y
- <Availability.h> __MAC_OS_X_VERSION_* SDK/DT macros are only
available when targeting macOS, while <AvailabilityMacros.h>
MAC_OS_X_VERSION_* SDK/DT macros are available on all Apple platforms,
which may be a source of confusion. (<Availability.h> __MAC_* macros
do remain available on all Apple platforms.)
This change was made mostly mechanically by:
sed -i '' -Ee 's/<AvailabilityMacros.h>/<Availability.h>/g' \
$(git grep -E -l '<AvailabilityMacros.h>' |
grep -v AvailabilityMacros.h)
sed -i '' -Ee 's/(MAC_OS_X_VERSION_(MIN_REQUIRED|MAX_ALLOWED))/__\1/g' \
$(git grep -E -l 'MAC_OS_X_VERSION_(MIN_REQUIRED|MAX_ALLOWED)' |
grep -v AvailabilityMacros.h)
sed -i '' -Ee 's/(MAC_OS_X_VERSION_(10_[0-9]+))/__MAC_\2/g' \
$(git grep -E -l 'MAC_OS_X_VERSION_(10_[0-9]+)' |
grep -v AvailabilityMacros.h)
Bug: crashpad:347
Change-Id: Ibdcd7a6215a82f7060b7b67d98691f88454085fc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2382421
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
hw.cputype is just CPU_TYPE_ARM64, which isn’t terribly useful.
hw.cpufamily is somewhat better as it uses <mach/machine.h> CPUFAMILY_*
values, which distinguish between different CPU generations.
CPUFAMILY_ARM_VORTEX_TEMPEST identifies A12, for example. (The fun cores
are Vortex and the boring cores are Tempest.)
Bug: crashpad:345
Change-Id: I88be4fa0b305b2fa15bd24358f63dc7d72192b27
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2289041
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This gets all tests building. They don’t all pass, and there aren’t any
guarantees that anything else works yet, either.
This is mostly a lot of CPU context shuffling.
Bug: crashpad:345
Change-Id: I684017a5816f44917392964d7fb6d08083770b38
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2285962
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This gets all production code for Chrome building, excluding tests.
There aren’t any guarantees that anything works yet.
This is mostly a lot of CPU context shuffling.
In contrast to macOS on x86, there’s no need to support 32-bit arm on
macOS, because this new platform is 64-bit-only from its inception.
Bug: crashpad:345
Change-Id: I187239b6a969005a3458af7fe30c44147a57f95f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2285961
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
If the file just needs the CHECK/CHECK_OP/NOTREACHED
macros, use the appropriate header for that instead.
Or if logging.h is not needed at all, remove it.
This is both a nice cleanup (logging.h is a big header,
and including it unnecessarily has compile-time costs),
and part of the final step towards making logging.h no
longer include check.h and the others.
Bug: chromium:1031540
Change-Id: Ia46806bd95fe498bcf3cf6d2c13ffa4081678043
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2255361
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Add direct includes for things provided transitively by logging.h
(or by other headers including logging.h).
This is in preparation for cleaning up unnecessary includes of
logging.h in header files (so if something depends on logging.h,
it needs include it explicitly), and for when Chromium's logging.h
no longer includes check.h, check_op.h, and notreached.h.
DEPS is also updated to roll mini_chromium to ae14a14ab4 which
includes these new header files.
Bug: chromium:1031540
Change-Id: I36f646d0a93854989dc602d0dc7139dd7a7b8621
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2250251
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
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 comment from d3859d91fde0, which referred to 10.14.4 as
the OS version where kern.nx stoppoed working. Testing indicates that
kern.nx works in 10.13.6 17G12034 and 10.14.4 18E226. It does not work
in 10.14.5 18F132 or 10.15.4 19E266.
Bug: crashpad:295
Change-Id: Id2f222700fb626de707d60980fedbd79e62990e6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2127566
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Gather most of the necessary information for the thread 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.
Change-Id: I80ba323cb6a59ac0dd1bba9150d047ba83cc4dad
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2085572
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
The current 10.14 SDK is numbered 101404, which is greater than
MAC_OS_X_VERSION_10_14 (101400). That was causing the test to
unintentionally fall into the “unlisted SDK” branch of the #if cascade
due to testing SDK <= MAC_OS_X_VERSION_10_14. This is corrected by
testing SDK < MAC_OS_X_VERSION_10_15 instead.
Bug: chromium:1016314, crashpad:310
Change-Id: If062e8fca92ae105924addf10c3e2fde162448cf
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1872636
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
macOS 10.15 (“Catalina”) introduces a single new field to its
dyld_all_image_infos structure, and uses structure version 16.
macOS 10.13 and 10.14 were documented in <mach-o/dyld_images.h> as using
structure version 16, but they actually use version 15. They should have
used version 16, as they do use a structure expanded from macOS 10.12,
which also uses version 15. Previously, process_types was true to the
documentation, but now that this is known to be incorrect, it’s been
revised to reflect reality. Because two variants of the version 15
structure exist, run-time OS version detection is used to disambiguate.
Bug: crashpad:310
Test: crashpad_snapshot_test ProcessTypes.DyldImagesSelf (10.15 SDK)
Change-Id: Ibc82b6a73809949f4bbf416ece7aa955b627c573
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1852109
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Also remove MemorySnapshotWin since the code is identical to
MemorySnapshotGeneric now.
Bug: crashpad:95
Change-Id: I9a631f8eb206dd72a69158021db87e8db41c5913
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1642148
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Until now we've been stuffing ELF debug symbol link information into a
CodeViewPDB70. This has reached the limits of its usefulness. We now add
a CodeViewRecord that can contain a proper ELF build ID.
Change-Id: Ice52cb2a958a1b9031943f280d9054da02d2f17d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1574107
Commit-Queue: Casey Dahlin <sadmac@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These changes were made in the upstream version of crashpad without
being contributed back to crashpad.
Bug: crashpad:271
Change-Id: I60f6dfd206191e65bac41978a7c88d06b8c3cee9
Reviewed-on: https://chromium-review.googlesource.com/c/1389238
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is a follow-up to c8a016b99d97, following the post-landing
discussion at
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7
base::size, and std::size that will eventually replace it when C++17 is
assured, does not allow the size of non-static data members to be taken
in constant expression context. The remaining uses of ArraySize are in:
minidump/minidump_exception_writer.cc (×1)
minidump/minidump_system_info_writer.cc (×2, also uses base::size)
snapshot/cpu_context.cc (×4, also uses base::size)
util/misc/arraysize_test.cc (×10, of course)
The first of these occurs when initializing a constexpr variable. All
others are in expressions used with static_assert.
Includes:
Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao
f701716d9546 Add Windows ARM64 build target to mini_chromium
87a95a3d6ac2 Remove the arraysize macro
1f7255ead1f7 Placate MSVC in areas of base::size usage
737433ebade4 Add cast
Bug: chromium:837308
Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19
Reviewed-on: https://chromium-review.googlesource.com/c/1396108
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Plumb ProcessReaderMac::Memory() through to ProcessSnapshotMac::Memory()
and add consts where necessary to accomodate the type signature of
ProcessSnapshot::Memory().
Bug: crashpad:263
Change-Id: I2608979918bc201ae3561483ea52ed2092cbc1e2
Reviewed-on: https://chromium-review.googlesource.com/c/1387924
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Currently, TaskMemory implements the ProcessMemory interface almost
exactly; however, it's initialized using a constructor instead of an
Initialize method which makes it incompatible with a number of
ProcessMemory tests. Change its initialization to match the other
ProcessMemory classes.
Bug: crashpad:263
Change-Id: I8022dc3e1827a5bb398aace0058ce9494b6b6eb6
Reviewed-on: https://chromium-review.googlesource.com/c/1384447
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Add a method to the ProcessSnapshot to expose a ProcessMemory object to
allow reading memory directly from the underlying process.
CQ-DEPEND=CL:1278830
BUG=crashpad:262
Change-Id: Ied2a5510a9b051c7ac8c41cdd060e8daa531086e
Reviewed-on: https://chromium-review.googlesource.com/c/1315428
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
pthread_threadid_np() reports an incorrect thread ID after fork() on
macOS 10.14 (“Mojave”). See https://openradar.appspot.com/43843552. As a
workaround, use thread_info(…, THREAD_IDENTIFIER_INFO, …).
This uses MachThreadSelf(), which in turn uses pthread_mach_thread_np(),
which does not suffer from the same bug. As an alternative,
base::mac::ScopedMachSendRight(mach_thread_self()) could be used.
Bug: crashpad:249
Change-Id: I757d6e94236cff533b9c1326f028110b6d214ee5
Reviewed-on: https://chromium-review.googlesource.com/c/1318271
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
OpenCL modules that appeared as “cl_kernels” since 10.7 now show up in
10.14 as ad-hoc signed modules at
/private/var/db/CVMS/cvmsCodeSignObjXXXXXXXXXXXXXXXX (16 random
characters). The modules are unlinked from the filesystem once loaded.
Bug: crashpad:243
Change-Id: I00fdd1311d4e6cd4c9224ef54ac990ac1afb849c
Reviewed-on: https://chromium-review.googlesource.com/1142027
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Conversion to CPUContext is currently only implemented for x64.
Bug: crashpad:196
Change-Id: I3fb8541f70a6f8d6f12c02e6b17c78e07e195056
Reviewed-on: https://chromium-review.googlesource.com/1007967
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Pulls the concrete non-test implementations of MemorySnapshot out into a
template. They were effectively identical on Mac and Linux/Android, and
I was going to have to add another identical one for Fuchsia.
Unfortunately it needs to be a template because of the snapshot merging
template it calls that needs the platform-specific ProcessReader (so it
can't just pass in a base ProcessMemory in initialization instead).
This is used on Mac, Linux, Android, and Fuchsia, but there is still a
Windows implementation (different because its ProcessReader is a bit
different) and a test implementation.
Bug: crashpad:196
Change-Id: I4b5575fee0749e96b08e756be1f8380a2c994d7c
Reviewed-on: https://chromium-review.googlesource.com/929308
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Follows https://chromium-review.googlesource.com/c/374019/.
Causes MinidumpMemoryListWriter to merge all overlapping ranges before
writing the MINIDUMP_MEMORY_LIST. This is:
1) Necessary for the Google internal crash processor, which in some
cases attempts to read the raw memory (displaying ASAN red zones),
and aborts if there are any overlapping ranges in the minidump on
load;
2) Necessary for new-ish versions of windbg (see bug 216 below). It is
believed that this is a change in behavior in the tool that made
dumps with overlapping ranges unreadable;
3) More efficient. The .dmp for crashy_program goes from 306K to 140K
with this enabled. In Chrome minidumps where
set_gather_indirectly_referenced_memory() is used (in practice this
means Chrome Windows Beta, Dev, and Canary), the savings are expected
to be substantial.
Bug: crashpad:61, chromium:638370, crashpad:216
Change-Id: I969e1a52da555ceba59a727d933bfeef6787c7a5
Reviewed-on: https://chromium-review.googlesource.com/374539
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Change-Id: I4b247d7fae1a212350f8ffcf2bf5ba1fa730f5c1
Reviewed-on: https://chromium-review.googlesource.com/780339
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Crashpad has many tests that crash intentionally. Some of these are
gtest death tests, and others arrange for intentional crashes to test
Crashpad’s own crash-catching logic. On macOS, all of the gtest death
tests and some of the other intentional crashes were being logged by
ReportCrash, the system’s crash reporter. Since these reports
corresponded to intentional crashes, they were never useful, and served
only to clutter ~/Library/Logs/DiagnosticReports.
Since Crashpad is adept at handling exceptions on its own, this
introduces the “exception swallowing server”,
crashpad_exception_swallower, which is a Mach exception server that
implements a no-op exception handler routine for all exceptions
received. The exception swallowing server is established as the task
handler for EXC_CRASH and EXC_CORPSE_NOTIFY exceptions during gtest
death tests invoked by {ASSERT,EXPECT}_DEATH_{CHECK,CRASH}, and for all
child processes invoked by the Multiprocess test infrastructure. The
exception swallowing server is not in effect at other times, so
unexpected crashes in test code can still be handled by ReportCrash or
another crash reporter.
With this change in place, no new reports are generated in the
user-level ~/Library/Logs/DiagnosticReports or the system’s
/Library/Logs/DiagnosticReports during a run of Crashpad’s full test
suite on macOS.
Bug: crashpad:33
Change-Id: I13891853a7e25accc30da21fa7ea8bd7d1f3bd2f
Reviewed-on: https://chromium-review.googlesource.com/777859
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The handler will now be less strict about checking CrashpadInfo struct
sizes. Assuming the signature and version fields match:
- If the handler sees a struct smaller than it’s expecting, the module
was likely built with an earlier version of the client library, and
it’s safe to treat the unknown fields as though they were zero or
other suitable default values.
- If the handler sees a struct larger than it’s expecting, the module
was likely built with a later version of the client library. In that
case, actions desired by the client will not be performed, but this
is not otherwise an error condition.
The CrashpadInfo struct must always be at least large enough to contain
at least the size field. The signature and version fields are always
checked.
The section size must be at least as large as the size carried within
the struct. To account for possible section padding, strict equality is
not required.
Bug: chromium:784427
Test: crashpad_snapshot_test CrashpadInfoSizes_ClientOptions/*.*
Change-Id: Ibb0690ca6ed5e7619d1278a68ba7e893d55f19fb
Reviewed-on: https://chromium-review.googlesource.com/767709
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This wires up the annotation objects system of the client to the
snapshot production and minidump writing facilities.
Bug: crashpad:192
Change-Id: If7bb7625b140d71a15b84729372cbd0fd4bc63ef
Reviewed-on: https://chromium-review.googlesource.com/749870
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
This is causing crashpad_handler_test to fail in Debug on Windows.
Bug: crashpad:192
Change-Id: Icf3ff387050ee2becf471f4e7c3a75394b1dd436
Reviewed-on: https://chromium-review.googlesource.com/749792
Reviewed-by: Mark Mentovai <mark@chromium.org>
The design for running all Crashpad unit tests on Chromium’s try- and
buildbots involves pulling all tests into a single monolithic
crashpad_tests executable. Many Crashpad tests base the name of their
child executables or modules on the name of the main test executable.
Since the main test executable will have a different name in the
in-Chromium build, knowledge of the test executable name (referred to as
“module” here) needs to be added to the tests themselves.
This introduces TestPaths::BuildArtifact(), which allows the module name
to be specified. For Crashpad’s standalone build, the module name is
verified against the main test executable’s name.
TestPaths::BuildArtifact() can also locate paths in the alternate 32-bit
output directory for 64-bit Windows tests, taking on the responsibility
for what the new (5e9ed4cb9f69) TestPaths::Output32BitDirectory(), now
obsolete, did.
Bug: chromium:779790
Change-Id: I64c4a2190b6319e487c999812a7cfc512a75a700
Reviewed-on: https://chromium-review.googlesource.com/747536
Reviewed-by: Scott Graham <scottmg@chromium.org>
These are mostly -Wsign-compare warnings, with a -Wconstant-conversion
and a -Wunguarded-availability thrown in.
Bug: chromium:779790
Change-Id: Ic2103f3332ce57378db83eca7fa2569efec1a7b6
Reviewed-on: https://chromium-review.googlesource.com/746081
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
Nothing currently directs the handler to read these Annotation objects
from the target process, so they will not be read by Crashpad nor appear
in the minidump.
Bug: crashpad:192
Change-Id: I8ebabb4f5c77c5620b0d8e5036c3185eecfa4646
Reviewed-on: https://chromium-review.googlesource.com/717236
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The AnnotationSnapshot is the handler-side of the Annotation object,
which will store the annotation data when read by a ProcessReader.
Bug: crashpad:192
Change-Id: Ic65c95022c452522678c1070c27c429dd631fb64
Reviewed-on: https://chromium-review.googlesource.com/717197
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This introduces the Annotation object, used to declare typed
annotations, and the AnnotationList object, used to reference these. The
AnnotationList is referenced by the CrashpadInfo structure. Currently
nothing reads these.
The AnnotationList implements a lock-free linked list, into which
Annotation objects are added exactly once, when they are first set.
Clearing an Annotation merely marks it internally as such, rather than
removing it from the list.
Bug: crashpad:192
Change-Id: I72414b1f83d624c4ae323e09ecea8cfb69a68c5e
Reviewed-on: https://chromium-review.googlesource.com/547135
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Update mini_chromium to 7d6697ceb5cb5ca02fde3813496f48b9b1d76d0c
47ff9691450e Switch the language standard to C++14
7d6697ceb5cb Remove base/memory/ptr_util.h and base::WrapUnique
base::WrapUnique and std::make_unique are similar, but the latter is
standardized and preferred.
Most of the mechanical changes were made with this sed:
for f in $(git grep -l base::WrapUnique | uniq); do
sed -E \
-e 's%base::WrapUnique\(new ([^(]+)\((.*)\)\);%std::make_unique<\1>(\2);%g' \
-e 's%base::WrapUnique\(new ([^(]+)\);%std::make_unique<\1>();%g' \
-e 's%^#include "base/memory/ptr_util.h"$%#include <memory>%' \
-i '' "${f}"
done
Several uses of base::WrapUnique that did not fit on a single line and
were not matched by this sed were adjusted manually. All #include
changes were audited manually, to at least move <memory> into the
correct section. Where <memory> was already #included by a file (or its
corresponding header), the extra #include was removed. Where <memory>
should have been #included by a header, it was added. Other similar
adjustments to other #includes were also made.
Change-Id: Id4e0baad8b3652646bede4c3f30f41fcabfdbd4f
Reviewed-on: https://chromium-review.googlesource.com/714658
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
1) Add PtraceConnection which serves as the base class for specific
types of connections Crashpad uses to trace processes.
2) Add DirectPtraceConnection which is used when the handler process
has `ptrace` capabilities for the target process.
3) Move `ptrace` logic into Ptracer. This class isolates `ptrace` call
logic for use by various PtraceConnection implementations.
Bug: crashpad:30
Change-Id: I98083134a9f7d9f085e4cc816d2b85ffd6d73162
Reviewed-on: https://chromium-review.googlesource.com/671659
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
This is essentially based on a search for “^const .*=”.
Change-Id: I9332c1f0cf7c891ba1ae373dc537f700f9a1d956
Reviewed-on: https://chromium-review.googlesource.com/585452
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
This is essentially based on a search for “^ *const [^*&]*=[^(]*$”
Change-Id: Id571119d0b9a64c6f387eccd51cea7c9eb530e13
Reviewed-on: https://chromium-review.googlesource.com/585555
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
This uses “static” at function scope to avoid making local copies, even
in cases where the compiler can’t see that the local copy is
unnecessary. “constexpr” adds additional safety in that it prevents
global state from being initialized from any runtime dependencies, which
would be undesirable.
At namespace scope, “constexpr” is also used where appropriate.
For the most part, this was a mechanical transformation for things
matching '(^| )const [^=]*\['.
Similar transformations could be applied to non-arrays in some cases,
but there’s limited practical impact in most non-array cases relative to
arrays, there are far more use sites, and much more manual intervention
would be required.
Change-Id: I3513b739ee8b0be026f8285475cddc5f9cc81152
Reviewed-on: https://chromium-review.googlesource.com/583997
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
In 10.13, modules loaded from the dyld shared cache appear with __TEXT
segments that have a nonzero “fileoff” (file offset). Previously, the
fileoff was always 0. Previously, the fileoff for segments in the dyld
shared cache was the actual offset into the shared cache (not 0), but
special consideration was given to __TEXT segments which were forced to
0. See 10.12.4 dyld-433.5/interlinked-dylibs/OptimizerLinkedit.cpp
LinkeditOptimizer<>::updateLoadCommands(). Note the comment there where
the __TEXT segment’s apparent fileoff is set to 0:
// HACK until lldb fixed in: <rdar://problem/20357466>
// DynamicLoaderMacOSXDYLD fixes for Monarch dyld shared cache
Refer also to the lldb commit that references the above,
http://llvm.org/viewvc/llvm-project?view=revision&revision=233714.
Evidently, update_dyld_shared_cache has been revised to no longer apply
this hack in 10.13. Crashpad’s sanity check for __TEXT segments having a
fileoff of 0 is no longer valid, and causes it to reject modules loaded
from the dyld shared cache.
Since this was just a sanity check, remove it entirely.
This caused module information for modules loaded from the dyld shared
cache to be missing from minidumps produced on 10.13, which in turn
prevented symbolization in frames belonging to most system libraries.
For reasons not yet understood, I don’t see this problem in Chrome on
10.13db1 17A264c on a test virtual machine (HFS+ filesystem), although I
do see it on actual hardware (APFS filesystem), and I do see it in
Crashpad’s tests and reduced testcases on both as well.
Bug: crashpad:185, crashpad:189
Test: crashpad_snapshot_test MachOImageReader.Self_DyldImages:ProcessReader.SelfModules:ProcessReader.ChildModules:ProcessTypes.DyldImagesSelf
Change-Id: I8b0a22c55c33ce920804a879f6fab67272f3556e
Reviewed-on: https://chromium-review.googlesource.com/535576
Reviewed-by: Robert Sesek <rsesek@chromium.org>
10.13 introduces two new fields to dyld_all_image_infos. Oddly, it
doesn’t put them in the “reserved” area that was defined in this
structure. This addition made it necessary for the padding problem in
the 32-bit structure previously worked around in Crashpad to be
addressed in the native structure, so Crashpad’s definition is adapted
to match.
This fixes tests on 10.13 that verify that dyld_all_image_infos can be
interpreted correctly.
Note that although the 10.13 SDK includes this structure extension,
numbered version 16, 10.13db1 17A264c continues to use version 15 as
used on 10.12, at least in crashpad_snapshot_test.
Bug: crashpad:185
Test: crashpad_snapshot_test ProcessTypes.DyldImagesSelf
Change-Id: I59a80c85bb234ef698c65a0ac5bbeac5b40fda77
Reviewed-on: https://chromium-review.googlesource.com/535394
Reviewed-by: Robert Sesek <rsesek@chromium.org>
_dyld_get_all_image_infos() was only used in test code in Crashpad.
This addresses two related problems.
When running on 10.13 or later, _dyld_get_all_image_infos() is not
available. It appears to still be implemented in dyld, but its symbol is
now private. This was always known to be an “internal” interface. When
it’s not available, fall back to obtaining the address of the process’
dyld_all_image_infos structure by calling task_info(…, TASK_DYLD_INFO,
…). Note that this is the same thing that the code being tested does,
although the tests are not rendered entirely pointless because the code
being tested consumes dyld_all_image_infos through its own
implementation of an out-of-process reader interface, while the
dyld_all_image_infos data obtained by _dyld_get_all_image_infos() is
handled strictly in-process by ordinary memory reads. This is covered by
bug 187.
When building with the 10.13 SDK, no _dyld_get_all_image_infos symbol is
available to link against. In this case, access the symbol strictly at
runtime via dlopen() if it may be available, or when expecting to only
run on 10.13 and later, don’t even bother looking for this symbol. This
is covered by part of bug 188.
Bug: crashpad:185, crashpad:187, crashpad:188
Change-Id: Ib283e070faf5d1ec35deee420213b53ec24fb1d3
Reviewed-on: https://chromium-review.googlesource.com/534633
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Since Apple closed https://openradar.appspot.com/20239912 without fixing
anything, it looks like we’ll be stuck with these quriky cl_kernels
modules for quite some time. Allow these modules to be tolerated on any
OS version >= 10.10, where they first appeared in a broken state, by
removing the upper bound for the OS version to tolerate with this quirk.
The tolerance was previously expanded to include 10.11 in
cd1f8fa3d2f2c76802952beac71ad85f51bbf771 and 10.12 in
6fe7c5414e46acfa30e8984513bf0896e91b9407. After this third update, this
should hopefully no longer be an annual exercise.
Bug: crashpad:185, crashpad:186
Change-Id: I66d409f2d1638bcf7601b6622f000be245230f34
Reviewed-on: https://chromium-review.googlesource.com/534253
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
I opted to leave casts to types that were definitely the same size
alone. reinterpret_cast<uintptr_t>(pointer) and
reinterpret_cast<intptr_t>(pointer) should always be safe, for example.
Casts to other integral types have been replaced with
FromPointerCast<>(), which does zero-extension or sign-extension based
on the target type.
To make it possible to use FromPointerCast<>() with some use sites that
were already using checked_cast<>(), FromPointerCast<>() now uses
check_cast<>() when converting to a narrower type.
Test: crashpad_util_test FromPointerCast*, others
Change-Id: I4a71b4aa2d87f545c75524290a702f5f3138d675
Reviewed-on: https://chromium-review.googlesource.com/489701
Reviewed-by: Scott Graham <scottmg@chromium.org>
gtest used to require (expected, actual) ordering for arguments to
EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify
each side as “expected” or “actual.” Tests in Crashpad adhered to this
traditional ordering. After a gtest change in February 2016, it is now
agnostic with respect to the order of these arguments.
This change mechanically updates all uses of these macros to (actual,
expected) by reversing them. This provides consistency with our use of
the logging CHECK_EQ and DCHECK_EQ macros, and makes for better
readability by ordinary native speakers. The rough (but working!)
conversion tool is
https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py,
and “git cl format” cleaned up its output.
EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made
a judgment that one side or the other needed to provide an “unexpected”
value. Consequently, some code used (unexpected, actual) while other
code used (actual, unexpected). For consistency with the new EXPECT_EQ
and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE,
this change also updates these use sites to (actual, unexpected) where
one side can be called “unexpected” as, for example, std::string::npos
can be. Unfortunately, this portion was a manual conversion.
References:
https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison77d6b17338https://github.com/google/googletest/pull/713
Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3
Reviewed-on: https://chromium-review.googlesource.com/466727
Reviewed-by: Scott Graham <scottmg@chromium.org>
This supports the “double handler” or “double handler with low
probability” models from https://crashpad.chromium.org/bug/143.
For crashpad_handler to be become its own client, it needs access to its
own executable path to pass to CrashpadClient::StartHandler(). This was
formerly available in the test-only test::Paths::Executable(). Bring
that function’s implementation to the non-test Paths::Executable() in
util/misc, and rename test::Paths to test::TestPaths to avoid future
confusion.
test::TestPaths must still be used to access TestDataRoot(), which does
not make any sense to non-test code.
test::TestPaths::Executable() is retained for use by tests, which most
likely prefer the fatal semantics of that function. Paths::Executable()
is not fatal because for the purposes of implementing the double
handler, a failure to locate the executable path (which may happen on
some systems in deeply-nested directory hierarchies) shouldn’t cause the
initial crashpad_handler to abort, even if it does prevent a second
crashpad_handler from being started.
Bug: crashpad:143
Test: crashpad_util_test Paths.*, crashpad_test_test TestPaths.*
Change-Id: I9f75bf61839ce51e33c9f7c0d7031cebead6a156
Reviewed-on: https://chromium-review.googlesource.com/466346
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
macOS 10.12.4 includes an updated timezone database. Abbreviations for
Australia/Eucla (formerly ACWST, now +0845) and Australia/Lord_Howe
(formerly LHST/LHDT, now +1030/+11) were dropped in IANA TZ 2017a. The
test is updated so that the abbreviations for these two time zones are
no longer checked.
References:
a25d615495https://mm.icann.org/pipermail/tz/2017-February/024837.html
Test: crashpad_snapshot_test SystemSnapshotMacTest.TimeZone
Change-Id: I2845c6aee7b7b6a8fcdc6faa4d5cefe5e0f72e5c
Reviewed-on: https://chromium-review.googlesource.com/461500
Reviewed-by: Scott Graham <scottmg@chromium.org>
952f787f4aab missed two occurrences that should have been updated.
Change-Id: I425367689eb19edfd309a2210a79ed400e190673
Reviewed-on: https://chromium-review.googlesource.com/458116
Reviewed-by: Robert Sesek <rsesek@chromium.org>
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Lazy initialization is particularly beneficial for Is64Bit(), which uses
a different (ptrace()-based) approach than the rest of the class (which
is /proc-based). It is possible for the /proc-based Initialize() to
succeed while ptrace() would fail, as it typically would in the
ProcessInfo.Pid1 test. Because this test does not call Is64Bit(),
permission to ptrace() shouldn’t be necessary, and in fact ptrace()
shouldn’t even be called.
This enables the ProcessInfo.Pid1 test on Android (due to ptrace(), it
was actually failing on any Linux, not just Android). It also enables
the ProcessInfo.Forked test on non-Linux, as the prctl(PR_SET_DUMPABLE)
Linux-ism can be removed from it.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: Ic883733a6aed7e7de9a0f070a5a3544126c7e976
Reviewed-on: https://chromium-review.googlesource.com/455656
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Apple has responded to their bug 29079442 with a resolution stating that
these are not corpse ports but task ports that have changed after
execve(), as part of the large task port and execve() strategy rewrite
from 10.12.1. The comments being replaced were written before we had
10.12.1 source code. Now that we can see what’s going on, revise the
comments, and re-enable the task port check for the non-execve() test
variants.
https://openradar.appspot.com/29079442https://googleprojectzero.blogspot.com/2016/10/taskt-considered-harmful.html
Bug: crashpad:137
Test: crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld
Change-Id: I463637816085f4165b92b85a5b98bfeddcdf4094
Reviewed-on: https://chromium-review.googlesource.com/451120
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
In locations where daylight saving time was once observed or is expected
to be observed in the future, but where no transitions to or from
daylight saving time occurred or will occur within a year of the current
date, act as though DST is not being observed at all.
Set TZ=America/Phoenix to test for this bug.
BUG=crashpad:130
TEST=crashpad_snapshot_test SystemSnapshotMacTest.TimeZone
Change-Id: Ie466b5906eab3c0cf2e51b962a171acb5b16210b
Reviewed-on: https://chromium-review.googlesource.com/438004
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The 32-bit process_types definition of dyld_all_image_infos winds up
with four extra bytes of tail padding when built into a 64-bit
crashpad_handler compared to a 32-bit one, and compared to the
structure’s native size. This prevents a 64-bit crashpad_handler from
being able to create a module snapshot of a 32-bit process for
dyld_all_image_infos versions 14 (since 10.9) and 15 (since 10.12).
Work around this by placing a zero-length “end” marker and using
offsetof(dyld_all_image_infos, end) in preference to
sizeof(dyld_all_image_infos).
BUG=crashpad:156,crashpad:148,crashpad:120
TEST=crashpad_snapshot_test ProcessTypes.DyldImagesSelf,
run_with_crashpad --handler=crashpad_handler{,32} builtin_trap{,32}
Change-Id: I406ad53851b5bd29ec802b7ad3073836ebe8c34c
Reviewed-on: https://chromium-review.googlesource.com/437924
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Previously, only the top-level exception code was reported via the
Crashpad.ExceptionCode.Mac histogram. Making this histogram work
(https://crbug.com/678720) has revealed that Chrome is triggering
EXC_RESOURCE exceptions at a rate in excess of 4x that of ordinary
crashes. These exceptions were not previously visible because they are
not uploaded unless the system treats them as fatal, which it does not
normally do absent an explicit request.
In order to learn more about the problem, this change augments the data
reported via the Crashpad.ExceptionCode.Mac histogram to report (at
least) second-level exception data. This means that we will no longer
see just EXC_RESOURCE, but potentially more useful information such as
EXC_RESOURCE / RESOURCE_TYPE_IO / FLAVOR_IO_PHYSICAL_WRITES. This also
applies to other exception types, so that the majority of crashes
currently falling into the EXC_CRASH bucket will now have additional
information decoded and will be reported as, for example, EXC_BAD_ACCESS
/ KERN_INVALID_ADDRESS, EXC_BAD_INSTRUCTION / EXC_I386_INVOP, and
EXC_CRASH / SIGABRT.
Because the old mechanism was only live (in an “it works” sense) for
several days, and the new mechanism does not overlap with histogram
values used by the old one, there’s no need to invent a new histogram
name.
BUG=chromium:684051
Change-Id: Ia0a372b4127f7b3b2e7dbbaac9304cce3b5aadfe
Reviewed-on: https://chromium-review.googlesource.com/430933
Reviewed-by: Scott Graham <scottmg@chromium.org>
This makes Doxygen’s output more actionable by setting QUIET = YES to
suppress verbose progress spew, and WARN_IF_UNDOCUMENTED = NO to prevent
warnings for undocumented classes and members from being generated. The
latter is too noisy, producing 721 warnings in the current codebase.
The remaining warnings produced by Doxygen were useful and actionable.
They fell into two categories: abuses of Doxygen’s markup syntax, and
missing (or misspelled) parameter documentation. In a small number of
cases, pass-through parameters had intentionally been left undocumented.
In these cases, they are now given blank \param descriptions. This is
not optimal, but there doesn’t appear to be any other way to tell
Doxygen to allow a single parameter to be undocumented.
Some tricky Doxygen errors were resolved by asking it to not enter
directiores that we do not provide documentation in (such as the
“on-platform” compat directories, compat/mac and compat/win, as well as
compat/non_cxx11_lib) while allowing it to enter the
“off-platform” directories that we do document (compat/non_mac and
compat/non_win).
A Doxygen run (doc/support/generate_doxygen.sh) now produces no output
at all. It would produce warnings if any were triggered.
Not directly related, but still relevant to documentation,
doc/support/generate.sh is updated to remove temporary removals of
now-extinct files and directories. doc/appengine/README is updated so
that a consistent path to “goapp” is used throughout the file.
Change-Id: I300730c04de4d3340551ea3086ca70cc5ff862d1
Reviewed-on: https://chromium-review.googlesource.com/408812
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Use “macOS” as the generic unversioned name of the operating system in
comments. For version-specific references, use Mac OS X through 10.6, OS
X from 10.7 through 10.11, and macOS for 10.12.
Change-Id: I1ebee64fbf79200bc799d4a351725dd73257b54d
Reviewed-on: https://chromium-review.googlesource.com/408269
Reviewed-by: Robert Sesek <rsesek@chromium.org>
crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld was failing
on 10.12.1. In 10.12, dyld’s intentional crashes come through
abort_with_payload(). In 10.12.1, it appears that the task port sent
along with abort_with_payload() crashes is now a corpse port, which has
a different port name than the task port that it originated from.
https://openradar.appspot.com/29079442
TEST=crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld
BUG=crashpad:137
Change-Id: I43f89c0f595dd5614fc910fa1f19f21ddf0a7c4d
Reviewed-on: https://chromium-review.googlesource.com/407087
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This defines the global (per-module) CrashpadInfo structure properly on
Linux/Android, located via the “crashpad_info” section name.
Per the ELF specification, section names with a leading dot are reserved
for the system. Reading that, I realized that the same is true of Mach-O
sections with leading underscores, so this renames the section as used
on Mach-O from __DATA,__crashpad_info to __DATA,crashpad_info.
This change is sufficient to successfully build crashpad_client as a
static library on Linux/Android, but the library is incomplete. There’s
no platform-specific database implementation, no CaptureContext() or
CRASHPAD_SIMULATE_CRASH() implementation, and most notably, no
CrashpadClient implementation.
BUG=crashpad:30
Change-Id: I29df7b0f8ee1c79bf8a19502812f59d4b1577b85
Reviewed-on: https://chromium-review.googlesource.com/406427
Reviewed-by: Robert Sesek <rsesek@chromium.org>
In 10.12, dyld calls abort_with_payload() on fatal error from
dyld::halt(). In previous 10.12 betas, abort_with_payload() caused the
process to appear to terminate as exit(1). This was weird, so I filed
https://openradar.appspot.com/26894758. In 10.12db4 16A270f, Apple seems
to have fixed this bug. abort_with_payload() as used by dyld now causes
the process to appear to terminate as abort() as I had requested.
A Crashpad test that assures Crashpad’s ability to catch dyld crashes
needs its expectations updated with each change to a process’ apparent
termination code. It’s updated to expect SIGABRT on 10.12 or later. No
concessions are made for previous 10.12 betas or their buggy exit(1)
behavior. Nobody should be running any 10.12 beta prior to 10.12db4
16A270f now or at any point in the future.
This undoes (redoes) 335ef494677f.
BUG=crashpad:120
TEST=crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld
Change-Id: I13b330ac83fc9b33907ac172d35983974b8910f0
Reviewed-on: https://chromium-review.googlesource.com/365920
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The layout of dyld_all_image_infos changed slightly in 10.12db3 16A254g
and Xcode 8b3 8S174q.
BUG=crashpad:120
TEST=crashpad_snapshot_test ProcessTypes.DyldImagesSelf
Change-Id: I66fb60c80b26f465913f5100a8c40564723b0021
Reviewed-on: https://chromium-review.googlesource.com/361800
Reviewed-by: Robert Sesek <rsesek@chromium.org>
exit(1) is a weird code for this, so I filed
https://openradar.appspot.com/26894758.
This doesn’t completely fix bug crashpad:121 unless both
crashpad_snapshot_test and crashpad_snapshot_test_no_op are signed with
the same Developer ID certificate. I’m hoping to get some action on
https://openradar.appspot.com/26902656, which will enable a complete fix
for this bug in unsigned developer builds. It would be unusual to have
to sign test executables.
BUG=crashpad:120,crashpad:121
TEST=crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld
Change-Id: I54fdfaa9178029b91ea3cbc12f2760dfa5124858
Reviewed-on: https://chromium-review.googlesource.com/355260
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The Mach-O reader validated segment and section file offsets by checking
that they were relative to the same base, insisting that a section’s
file offset be the same distance from a segment’s file offset as the
section’s preferred load address was from the segment’s preferred load
address. Notably, these file offsets already could not be validated
against the Mach-O image’s start because in the dyld shared cache, for
all segments other than __TEXT, these offsets were relative to the dyld
shared cache’s start.
In 10.12dp1 16A201w, file offsets for sections in the __TEXT segment are
also relative to the dyld shared cache’s start, but the file offset for
the __TEXT segment itself is relative to the Mach-O image’s start. Being
relative to different positions breaks Crashpad’s sanity check of the
module data. https://openradar.appspot.com/26864860 is filed for the use
of distinct bases in what should be related file offset fields.
While it would be possible with a bit of work to identify modules within
the dyld shared cache and adjust expectations accordingly, in reality,
these file offset values were only used to verify that the Mach-O
module.
In addition, the file offsets stored within the Mach-O file for sections
are 32-bit quantities, even in 64-bit images. It is possible to create a
large image whose section offset values have overflowed, and in these
cases, the offset value verification would also fail.
For these reasons, all file offset value validation is removed from the
Mach-O image reader.
BUG=crashpad:118, crashpad:120
Change-Id: I9c4bcc5fd0aeceef3bc8a43e5a8651735852d87b
Reviewed-on: https://chromium-review.googlesource.com/353631
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Add a user-configurable cap on the amount of memory that is gathered by
dereferencing thread stacks. (SyzyAsan stores a tremendously large
number of pointers on the stack, so the dumps were ending up in the ~25M
range.)
Also reduce the range around pointers somewhat.
Change-Id: I6bce57d86bd2f6a796e1580c530909e089ec00ed
Reviewed-on: https://chromium-review.googlesource.com/338463
Reviewed-by: Mark Mentovai <mark@chromium.org>
CrashpadInfo not being initialized/propagated properly on Mac.
Change-Id: I5f33a16e4e18bb1b068e0d4aeb7f2032a6cb6278
Reviewed-on: https://chromium-review.googlesource.com/324500
Reviewed-by: Mark Mentovai <mark@chromium.org>
This was done in Chromium’s local copy of Crashpad in 562827afb599. This
change is similar to that one, except more care was taken to avoid
including headers from a .cc or _test.cc when already included by the
associated .h. Rather than using <stddef.h> for size_t, Crashpad has
always used <sys/types.h>, so that’s used here as well.
This updates mini_chromium to 8a2363f486e3a0dc562a68884832d06d28d38dcc,
which removes base/basictypes.h.
e128dcf10122 Remove base/move.h; use std::move() instead of Pass()
8a2363f486e3 Move basictypes.h to macros.h
R=avi@chromium.org
Review URL: https://codereview.chromium.org/1566713002 .
This makes the basics of !peb work in windbg, however, pointed-to things
are not yet retrieved. For full functionality, a variety of pointers in
the PEB also needs to be walked and captured.
e.g.
Previously:
0:000> .ecxr
eax=00000007 ebx=7e383000 ecx=c3f9a943 edx=00000000 esi=006d62d0 edi=003c9280
eip=00384828 esp=005bf634 ebp=005bf638 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
00384828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7e383000
error 1 InitTypeRead( nt!_PEB at 7e383000)...
Now:
0:000> .ecxr
eax=00000007 ebx=7f958000 ecx=02102f4d edx=00000000 esi=00e162d0 edi=01389280
eip=01344828 esp=00c2fb64 ebp=00c2fb68 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
01344828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7f958000
InheritedAddressSpace: No
ReadImageFileExecOptions: No
BeingDebugged: No
ImageBaseAddress: 01340000
Ldr 77ec8b40
*** unable to read Ldr table at 77ec8b40
SubSystemData: 00000000
ProcessHeap: 00e10000
ProcessParameters: 00e114e0
CurrentDirectory: '< Name not readable >'
WindowTitle: '< Name not readable >'
ImageFile: '< Name not readable >'
CommandLine: '< Name not readable >'
DllPath: '< Name not readable >'
Environment: 00000000
Unable to read Environment string.
R=mark@chromium.org
BUG=crashpad:46
Review URL: https://codereview.chromium.org/1364053002 .
CrashReportExceptionHandler::CatchMachException() must always set a
valid new_state. Failing to do so appears to trigger corpse generation
on OS X 10.11. This is addressed by calling ExcServerCopyState().
Previously, this was not done for exceptions forwarded to the user
ReportCrash, under the apparent mistaken assumption that ReportCrash
would do it. However, ReportCrash is given copies of out-parameters like
new_state to explicitly prevent it from influencing Crashpad’s returned
state.
ExcServerSuccessfulReturnValue() must not return MACH_RCV_PORT_DIED for
an EXC_CRASH handler on OS X 10.11. This appears to trigger corpse
generation. This is addressed by always returning KERN_SUCCESS from
EXC_CRASH handlers on OS X 10.11.
This also adds generic EXC_CORPSE_NOTIFY support throughout Crashpad.
The crashpad_handler does not listen for this exception type, but it is
now possible to work with this exception type using tools like
exception_port_tool and catch_exception_tool.
BUG=crashpad:48
TEST=Crashes handled by crashpad_handler do not result in the generation
of reports in the root /Library/Logs/DiagnosticReports.
R=kerrnel@chromium.org, rsesek@chromium.org
Review URL: https://codereview.chromium.org/1305893010 .
Calling std::vector<>::operator[]() with an out-of-range index argument
is undefined behavior. In two cases, Crashpad used &v[0] in situations
where it was known that the address would not be used. These calls were
wrapped in conditions guarding against vector emptiness.
While s[0] is valid on an empty string, in two cases, Crashpad used
&s[0] as an argument to a system call that would be a no-op. These calls
were wrapped in similar conditions to avoid the system call.
The two uses of vector with undefined behavior were caught by the
following tests in crashpad_snapshot_test with
UndefinedBehaviorSanitizer:
[ RUN ] CrashpadInfoClientOptions.OneModule
/Users/mark/compilatorium/llvm.build/bin/../include/c++/v1/vector:1493:12:
runtime error: reference binding to null pointer of type
'crashpad::process_types::section'
[ OK ] CrashpadInfoClientOptions.OneModule (72 ms)
[ RUN ] ProcessSnapshotMinidump.Empty
/Users/mark/compilatorium/llvm.build/bin/../include/c++/v1/vector:1493:12:
runtime error: reference binding to null pointer of type
'MINIDUMP_DIRECTORY'
[ OK ] ProcessSnapshotMinidump.Empty (1 ms)
The Crashpad codebase was audited by searching for resize() calls and
analyzing how resized strings and vectors are used.
TEST=*
BUG=
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1283243004 .
After 6083a2706d55, it is possible to determine the expected size of a
versioned structure such as dyld_all_image_infos. The expected size is
compared against the actual size of the structure as returned by
task_info() (TASK_DYLD_INFO).
TEST=crashpad_snapshot_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1272283004 .
