Fix a -Wextra-semi warning in Clang when building crashpad for MIPS.
Change-Id: I53893c815de74d2503acdce24708e29096f4b0aa
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1997103
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Tomasz Śniatowski <tsniatowski@vewd.com>
Since gtest 00938b2b228f, gtest has built-in first-class support for
skipping tests, which is functionally identical (at least in Crashpad’s
usage) to the home-grown support for run-time dynamically disabled tests
introduced in Crashpad 5e9ed4cb9f69.
Use the new standard pattern, and remove all vestiges of the custom
local one.
This was done previously in 79f4a3970a64, but was reverted in
bba9d0819c12 because Chromium’s test launcher did not support
GTEST_SKIP() at the time. The deficiency is on file as
https://crbug.com/912138.
While that bug was never specifically marked as “fixed” and I haven’t
found what changed in Chromium, I do now see some use of GTEST_SKIP() in
Chromium. I also prototyped this change in Chromium at
https://chromium-review.googlesource.com/c/1854691/ and found that
GTEST_SKIP() does indeed now appear to work.
Change-Id: I13fef8fe8bfd9854a40dfa5910a3282d1a85bc45
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1855380
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
When a crash dump request is received over a socket, the message
includes a stack address of the thread requesting the dump. This can
be used to override the ExceptionInfo's thread ID which may be
incorrect in the handler's PID namespace.
Bug: crashpad:286
Change-Id: I053cf709c5eeefb73b31328f16a806510e1bd35d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1759280
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
This is very similar to the windows implementation in
module_snapshot_win.cc.
Bug: crashpad:95
Change-Id: I3858e8bb0009c95395bfb7ca3855c3d937fd49d5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1641588
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Mark Mentovai <mark@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>
When a crashing process is in a different PID namespace than the
handler, the crasher doesn't have a way of knowing its own thread ID in
the handler's namespace and the kernel lacks mechanisms to perform this
translation before Linux 4.1 (where the information is present in
/proc/<pid>/status:NSPid).
This patch gives the handler a way of identifying the requesting thread
by sending a stack address along with the crash dump request, which
the handler can search for in each of the process' threads.
This information is useful both for attaching exception information
to the right thread and to allow the handler to send signals to the
correct thread when using a shared socket connection.
Bug: crashpad:284, crashpad:286
Change-Id: I4fa366c8fb17f932b056265cf71a4af160ba342f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1558828
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
As of Android Q, the android_set_abort_message() function copies the
abort message into a mapping with a specific name that starts with a magic
number. This makes it possible for Crashpad to collect the abort message
by looking for the mapping with this name in procmaps and checking for the
magic number. The abort message is stored in a process annotation named
"abort_message".
Test: No regressions in build/run_tests.py on devices running P and Q
Test: Patched into Chromium; manually verified that HWASAN crash report appears in minidump
Bug: crashpad:287
Change-Id: I23c4d9e11015c84341de2d2e47e38a1eec508a36
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1544875
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This patch fixes the following error:
../../third_party/crashpad/crashpad/snapshot/linux/cpu_context_linux.cc:246:12: error: 'numeric_limits' is not a member of 'std'
std::numeric_limits<decltype(context->spsr)>::max()) {
^~~~~~~~~~~~~~
../../third_party/crashpad/crashpad/snapshot/linux/cpu_context_linux.cc:246:27: error: expected primary-expression before 'decltype'
std::numeric_limits<decltype(context->spsr)>::max()) {
^~~~~~~~
../../third_party/crashpad/crashpad/snapshot/linux/cpu_context_linux.cc:246:27: error: expected ')' before 'decltype'
Bug: chromium:819294
Change-Id: I4f31a33fcdae9567c71a4d371d2e6afe68d2ef6a
Reviewed-on: https://chromium-review.googlesource.com/c/1454376
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Reviewed-by: Joshua Peraza <jperaza@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>
Add MemoryMap::Iterator to support different strategies for locating
the start of module mappings on Android and Linux.
Beginning with API 21, Bionic provides android_dlopen_ext() which
allows passing a file descriptor with an existing relro segment to the
loader. This means that the mapping containing the dynamic segment
could have a name, device, and inode which are different than the
other mappings for the module.
The revised strategy for Android at API 21+ is to search all mappings
in reverse order from they dynamic array mapping until a module is
parsed with the expected dynamic array address.
Linux and Android 20- continue to select mappings using the device,
inode, and file offsets of the mappings.
Bug: crashpad:268
Change-Id: I30e95e51cb6874c00875d2a9c57f1249877736d4
Reviewed-on: https://chromium-review.googlesource.com/c/1374375
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Add const to ProcessMemory pointers from ProcessReaderLinux::Memory().
This code is ifdef'd to only build on ARM/MIPS.
Change-Id: I93983a83d06bd5bd338b93babdb326fa94925c53
Reviewed-on: https://chromium-review.googlesource.com/c/1341228
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@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>
Modules mapped from zipfiles will have mappings named for the zipfile
rather than the module name and an offset into that zipfile instead of
0.
Bug: crashpad:253, crashpad:254
Change-Id: I0503d13e7b80ba7bd1cc2d241633d9c68c98f1cd
Reviewed-on: https://chromium-review.googlesource.com/1232294
Reviewed-by: Mark Mentovai <mark@chromium.org>
SELinux blocks the handler from collecting these values on Android M.
They should eventually be collected via the broker.
Change-Id: Iad47759b2ebf23148cb5b2c401241ee87f8ffd27
Reviewed-on: https://chromium-review.googlesource.com/1226120
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The general strategy used by Crashpad to determine loaded modules is to
read the link_map to get the addresses of the dynamic arrays for all
loaded modules. Those addresses can then be used to query the MemoryMap
to locate the module's mappings, and in particular the base mapping
from which Crashpad can parse the entire loaded ELF file.
ELF modules are typically loaded in several mappings with varying
permissions for different segments. The previous strategy used to find
the base mapping for a module was to search backwards from the mapping
for the dynamic array until a mapping from file offset 0 was found for
the same file. This fails when the file is mapped multiple times from
file offset 0, which can happen if the first page of the file contains
a GNU_RELRO segment.
This new strategy queries the MemoryMap for ALL mappings associated
with the dynamic array's mapping, mapped from offset 0. The consumer
(process_reader_linux.cc) can then determine which mapping is the
correct base by attempting to parse a module at that address and
corroborating the PT_DYNAMIC or program header table address from the
parsed module with the values Crashpad gets from the link_map or
auxiliary vector.
Bug: crashpad:30
Change-Id: Ibfcbba512e8fccc8c65afef734ea5640b71e9f70
Reviewed-on: https://chromium-review.googlesource.com/1139396
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These fixes are mostly related to address sanitizer causing stack
variables to not be stored on the call-stack. Attempting to disable
safe-stack has no effect.
Change-Id: Ib5718bfb74ce91dee560b397ccdbf68d78e4ec6a
Reviewed-on: https://chromium-review.googlesource.com/1140507
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
On GCC with libstdc++, ContextTraits fail to build because of the missing
declaration of offsetof (should include cstddef) and for aliasing a type
with the same name overriding previous declaration.
Change-Id: Ic497238122bcb430f14f9234644c483a8e27e3b6
Reviewed-on: https://chromium-review.googlesource.com/1114606
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: José Dapena Paz <jose.dapena@lge.com>
This is particularly a problem when the neighboring mapping is a
special mapping not readable from another process. For example:
7fff96aeb000-7fff96b0c000 rw-p 00000000 00:00 0 [stack]
7fff96b0c000-7fff96b0e000 r--p 00000000 00:00 0 [vvar]
[vvar] is a special mapping which makes some kernel data available
for virtual system calls. Attempting to read this region via the
/proc/<pid>/maps file returns an IO error which causes Crashpad to
abort capturing any of the thread's stack.
Neighboring mappings with empty names are eligible to be merged since
they result from changing permissions on existing named mappings.
Change-Id: I587bd2ec6f9759d284f1f9b1d93f2a44ddf61e92
Reviewed-on: https://chromium-review.googlesource.com/1072803
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Annotations data structures may be dynamically allocated so could
appear outside a modules's address range. Let ImageAnnotationReader
use a ProcessMemoryRange for the process, rather than the module.
Also add a test for linux.
Bug: crashpad:30
Change-Id: Ibbf1d2fcb2e44b1b70c8a02e86c6f2fbd784535f
Reviewed-on: https://chromium-review.googlesource.com/1054705
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@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>
Floating-point content may not begin at the start of __fpregs_mem and
should be located via mcontext.fpptr, which may be `nullptr`.
Bug: crashpad:30
Change-Id: Ie3116339d79f6669d757618e9e592f8480dcdcba
Reviewed-on: https://chromium-review.googlesource.com/1001332
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
This may be a bug in the target program or loader, but doesn't seem
like something worth dying over. If a link_entry name is empty,
ProcessReaderLinux::InitializeModules() will fall back to using the
name of the module's mapping. In this case, the main executable's
link entry name pointed into unmapped memory, but the memory map was
able to identify it as app_process32.
Bug: crashpad:30
Change-Id: Ic6df08132271efb809bf0bc28f23a333deb20a67
Reviewed-on: https://chromium-review.googlesource.com/999301
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This change:
1. Updates the broker's memory reading protocol to enable short reads.
2. Updates Ptracer to allow short reads.
3. Updates the broker to allow reading from a memory file.
4. Updates the broker's default file root to be "/proc/[pid]/".
5. Adds PtraceConnection::Memory() to produce a suitable memory reader
for a connection type.
Bug: crashpad:30
Change-Id: I8c004016065d981acd1fa74ad1b8e51ce07c7c85
Reviewed-on: https://chromium-review.googlesource.com/991455
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Some files, such as /proc/[pid]/maps, may not be accessible to the
handler. This enables the handler access to the contents of those files
via the broker.
This change reads maps and auxv using ReadFileContents.
Bug: crashpad:30
Change-Id: Ia19b498bae473c616ea794ab51c3f22afd5795be
Reviewed-on: https://chromium-review.googlesource.com/989406
Reviewed-by: Mark Mentovai <mark@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>
They were largely the same after recent changes, so with a bit at
initialization time the whole class can be de-duplicated.
Bug: crashpad:196, crashpad:30
Change-Id: I2f5df797dfe36e120090e570273b48ee03f660a5
Reviewed-on: https://chromium-review.googlesource.com/927611
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Placing a 32-bit pointer directly into a .quad results in either an
unsupported relocation error at link time (ARM) or an inability to
load the executable (x86).
Also, only attempt to read a module's CrashpadInfo if an info address
note was found.
Change-Id: I053af3d77eed70af66248be88547656d2b29878a
Reviewed-on: https://chromium-review.googlesource.com/922397
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Embeds the address of g_crashpad_info into a .note section (which is
readable by the generic code to read notes in ElfImageReader).
Unfortunately because the note section is in libclient.a, it would
normally be dropped at link time. To avoid that, GetCrashpadInfo() has
a reference *back* to that section, which in turn forces the linker to
include it, allowing the note reader to find it at runtime.
Previously, it was necessary to have the embedder of "client" figure out
how to cause `g_crashpad_info` to appear in the final module's dynamic
symbol table. With this new approach, there's no manual configuration
necessary, as it's not necessary for the symbol to be exported.
This is currently only implemented in the Linux module reader (and I
believe the current set of enabled tests aren't exercising it?) but it
will also be done this way for the Fuchsia implementation of
ModuleSnapshot.
Bug: crashpad:196
Change-Id: I599db5903bc98303130d11ad850ba9ceed3b801a
Reviewed-on: https://chromium-review.googlesource.com/912284
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@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>
ProcessReader module tests use dl_iterate_phdr to check that the
loader's modules appear in the ProcessReader's module vector, but
this API is not provided on Android for ARM until API 21.
Bug: crashpad:30
Change-Id: I7832bb5560f870671812c42345d4b59bf4416a26
Reviewed-on: https://chromium-review.googlesource.com/871972
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
