offsets in the MemoryMap are expressed as two's complement while
Crashpad's and mini_chromium's string conversion functions expect
negative numbers to be expressed with a '-' character.
Convert the string as unsigned and then re-interpret to signed when
necessary.
Bug: 914246
Change-Id: I76aaf092ea7ad98806be7a3f380dab4ca0425ed6
Reviewed-on: https://chromium-review.googlesource.com/c/1399372
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Fixes a -Wunused-value warning found by the latest version of clang.
R=mark@chromium.org
Bug: 917419
Change-Id: I6178c1534adc7e25e5b75f6a6ab90497a86de23f
Reviewed-on: https://chromium-review.googlesource.com/c/1395945
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Reid Kleckner <rnk@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>
Adds new scripts: mig_gen.py for using MIG to generate a Mach interface, mig_fix.py for fixing the resulting interface. mig.py now wraps both into the same user interface.
mig_fix.py also has the option to write its fixed output to new files, rather than overwriting the existing output. This should increase compatibility with certain build configurations.
Change-Id: I743ea1bab3f63c5b92f361948b544d498ed01cbc
Reviewed-on: https://chromium-review.googlesource.com/c/1389095
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
As Mark noted in [1] ProcessMemory should accept VMSize instead of
size_t, the two types can differ on platforms where a cross-bitness
handler could cause a 32-bit handler to inspect a 64-bit process. By
centralizing the checks in ProcessMemory, we can leave the individual
platform-specific implementations (in ProcessMemory*::ReadUpTo) to
accept size_ts.
[1] crrev.com/c/1388017/2/snapshot/crashpad_types/crashpad_info_reader.cc#70
Bug: crashpad:270
Change-Id: I3aab483221de36f3b1478cb9503101b142dae681
Reviewed-on: https://chromium-review.googlesource.com/c/1387756
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Didn't notice these until I hit presubmit in chromium.
Bug: crashpad:263
Change-Id: I7d86c508928c95a65b7972a19fbdf3bd19c9b29b
Reviewed-on: https://chromium-review.googlesource.com/c/1387885
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Delete TaskMemory tests made redundant by equivalent
ProcessMemoryTests. Some TaskMemory tests are still not redundant
because they test TaskMemory::ReadMapped() or they exercise platform-
specific behavior like TaskMemory::Read() not being able to read a
VM_PROT_NONE page.
Bug: crashpad:263
Change-Id: I72a56b4f3564444b02943f11a0069749bf1b074b
Reviewed-on: https://chromium-review.googlesource.com/c/1387270
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Currently TaskMemory re-implements a number of Read* routines that are
implemented in a platform-independent way in ProcessMemory with access
to a single platform-specific ReadUpTo method. Implement the ReadUpTo
method for TaskMemory and subclass it from ProcessMemory to inherit the
remaining methods.
The ProcessMemoryTests didn't work on macOS because MultiprocessExec
can not access the child process' task port without root privileges or
the task_for_pid entitlement. Create an adaptor class for those tests to
use MachMultiprocess so that the child process sends its task port to
the parent.
Bug: crashpad:263
Change-Id: Id8e1788a74fe957f05703a5eb569ca3bf9870369
Reviewed-on: https://chromium-review.googlesource.com/c/1387265
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Use platform independent helpers to simplify initializing a
ProcessMemory object in this test.
Bug: crashpad:263
Change-Id: Id0f9e006f6dbaca31453803b8c790a6832e855e5
Reviewed-on: https://chromium-review.googlesource.com/c/1387264
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>
Update the "...namespaces.md..." link to its current URL.
Change-Id: Ic30c6be5dba4f531e5b8a55af37555626398df5a
Reviewed-on: https://chromium-review.googlesource.com/c/1381777
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Currently, TaskMemory::ReadCStringInternal() treats the
ReadCStringSizeLimited(size=0) case by returning an empty string;
however, that is inconsistent with the documentation for that function
and the equivalent implementation in ProcessMemory. The comment for the
size parameter is: "The maximum number of bytes to read. The string is
required to be `NUL`-terminated within this many bytes." My
interpretation is that the ProcessMemory behavior is correct in failing
on size=0 as a NUL can never be read.
ReadCStringSizeLimited() is only used with a possibly null size in
MachOImageReader::ReadDylinkerCommand(). In that case we read the
dylinker_command string, which appears to also be verified to be a
non-zero length null terminated string in load_dylinker() in
bsd/kern/mach_loader.c so we shouldn't hit this case in the wild.
Bug: crashpad:263
Change-Id: I2bd9c0ce3055154a98afdd19af95bb48d05f05a3
Reviewed-on: https://chromium-review.googlesource.com/c/1384448
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@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>
ZX-1729 has been fixed upstream
Change-Id: Ia9c55b13169db650eb4ca0562434ae19a6f44eaf
Reviewed-on: https://chromium-review.googlesource.com/c/1366638
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
When building in Chromium:
../../third_party/crashpad/crashpad/util/process/process_memory_win.cc(95,74): error: format specifies type 'unsigned long long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
"range at 0x%llx, size 0x%llx completely inaccessible", address, size);
~~~~ ^~~~
%zx
../../third_party/crashpad/crashpad/util/process/process_memory_win.cc(103,72): error: format specifies type 'unsigned long long' but the argument has type 'size_t' (aka 'unsigned int') [-Werror,-Wformat]
"start of range at 0x%llx, size 0x%llx inaccessible", address, size);
Change-Id: I820f0afee28d1220ca400780eac61de05bde10ef
Reviewed-on: https://chromium-review.googlesource.com/c/1323771
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Also update gyp to build it.
Change-Id: I859c552b9cfc41f531ffb04fe6d6730dbd0e8fed
Reviewed-on: https://chromium-review.googlesource.com/c/1319269
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Currently, ProcessMemory is only implemented for Linux and Fuchsia.
Implement the interface for Windows as well and re-factor tests to
support it, mostly this consists of using a new ScopedGuardedPage class
instead of ScopedMmap in the ProcessMemory tests.
BUG=crashpad:262
Change-Id: I1b42718972be5ad838d12356d09f764053f09e4f
Reviewed-on: https://chromium-review.googlesource.com/c/1278829
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Dirents with short names can have a d_name that fits inside padding at
the end of Dirent64.
Change-Id: I18057dad01f5a7d4a063028ca9f61fbe89ae7fc0
Reviewed-on: https://chromium-review.googlesource.com/c/1310413
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Bug: fuchsia:ZX-2842
Change-Id: Ib84b4319d3bb07a2c68bc2ff0d63e49fa65eb2b5
Reviewed-on: https://chromium-review.googlesource.com/c/1292237
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Some of the minidump functionality is going to be used in Fuchsia in
host side tools (in zxdb, the debugger). This fixes the Mac-host build
of util.
Change-Id: Ifeb3bd9c7fa29c99a272c97c2813b9c201ddfe88
Reviewed-on: https://chromium-review.googlesource.com/c/1277774
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
The HTTPS tests are flaky on Fuchsia bots, so TLS transport was disabled.
However, a different CHECK fails in prod when a crash is attempted to be
uploaded via an 'https' url. So for now, re-enable the https transport,
but disable the https tests that were flaky, so they can be debugged
separately.
Additionally, there was a small error in
21edfd3c3a
that wasn't caught because these tests were disabled; fix the path to
test server certs on Fuchsia.
Bug: fuchsia:DX-382
Change-Id: I4ad0649ecb6d0644b1dfcf08bbb097d3a0cd40d0
Reviewed-on: https://chromium-review.googlesource.com/c/1265197
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Francois Rousseau <frousseau@google.com>
* instead of just 'Check failed: scheme == "http"', we will have something
like 'Check failed: scheme == "http". Got 'https' for scheme in 'https://for.bar''
* clangfmt on file
Bug: fuchsia:DX-514
Change-Id: I043af7281d7f99ed5641c87920d806e340a38dea
Tested=`out/Debug/crashpad_util_test` and Fuchsia logs
Reviewed-on: https://chromium-review.googlesource.com/c/1262140
Commit-Queue: Francois Rousseau <frousseau@google.com>
Reviewed-by: Scott Graham <scottmg@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>
The build broke because x30 was used instead of r14 in place of LR
which gcc doesn't recognize when building for 64-bit ARM. gcc does
recognize LR for 32-bit ARM, however, so revert to that since it's
more readable.
Also, de-duplicate saving of FP/IP which are synonyms of r11/r12,
saved above.
Change-Id: I8ae28f430cc3c47f4e4cf3679383ed5b94fadd2e
Reviewed-on: https://chromium-review.googlesource.com/1217483
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
When tested with GCC 6, it couldn't to understand LR register.
Thus, use x30 instead.
The error this patch fixes is the following:
Error: operand 1 must be an integer register -- `str LR,[x0,#0x1b8]'
Test: compile for aarch64
Change-Id: Icf1199254c6a29f72b6d2fa7940e1f33259a728b
Reviewed-on: https://chromium-review.googlesource.com/1213125
Commit-Queue: Maksim Sisov <msisov@igalia.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This will be useful to allow setting variables such as CLASSPATH or
LD_LIBRARY_PATH without modifying or depending upon the application's
current environment.
Bug: crashpad:30
Change-Id: I34f31bcc397e51d789b48eb654d80f992a719074
Reviewed-on: https://chromium-review.googlesource.com/1194399
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is a follow-up to e6f26587e435.
Bug: DX-382
Change-Id: I3116ea5dd2eca33961465d62c9200aa8dd1baf5d
Reviewed-on: https://chromium-review.googlesource.com/1173339
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Some crash recorders respond with non-200 2xx responses on success, e.g.
HockeyApp which responds with 202 Accepted.
Change-Id: I40de12155b44f7638a1c726090657938e3b1b557
Reviewed-on: https://chromium-review.googlesource.com/1167793
Commit-Queue: Jeremy Apthorp <jeremya@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The C++ http_transport_test_server was added in 439ba730c5ae and the
missing GYP build description was corrected in 0e144fb9aeff, but this
wasn’t complete for Windows. ws2_32.lib was missing.
Bug: crashpad:227
Change-Id: I2a0810468f857a02ad1a997c569eee6d9c05c7da
Reviewed-on: https://chromium-review.googlesource.com/1167210
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
__aarch64__ should always be defined for 64-bit ARM, while __arm64__
only sometimes is.
Change-Id: I46a6469d8f5e74ad79b6ded51a809fbf88e5170a
Reviewed-on: https://chromium-review.googlesource.com/1151541
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@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>
