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>
In preparation for deleting the custom CrashpadInfo reading routines in
the PEImageReader and also deleting the PEImageAnnotationsReader, this
change moves ModuleSnapshotWin to using the platform-independent
CrashpadInfoReader.
Bug: crashpad:270
Change-Id: Idad5de173200068243eacb2bb11b2d95b6438e90
Reviewed-on: https://chromium-review.googlesource.com/c/1388017
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: 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>
This API was added for Kasko several years ago but that project is
defunct and this API does not appear to be used elsewhere.
Bug: crashpad:270
Change-Id: I5a409deff7c5cf4f9f552893d4a49303f3000164
Reviewed-on: https://chromium-review.googlesource.com/c/1388022
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
In preparation for deleting the PEImageAnnotationsReader (and replacing
it with the generic ImageAnnotationsReader) change the
PEImageAnnotationsReader test to be a ModuleSnapshotWin test instead.
The tests are still useful for testing the annotations on the module
snapshot.
Bug: crashpad:270
Change-Id: Ibbbc69c72ca2eb98bfae9dc9b57bf28e9d3f12e2
Reviewed-on: https://chromium-review.googlesource.com/c/1388018
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>
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>
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>
This plumbs some of the ZX_INFO_PROCESS_MAPS information out into
MINIDUMP_MEMORY_INFO. The mapping loses some information that Zircon
provides, and some of the data that Windows would provide isn't
available (for example, AllocationProtect). But this gives a general
idea of the memory layout of the process to check for bad pointers, etc.
when inspecting crashes.
Bug: fuchsia:DX-615
Change-Id: I2d7c02be0996672253cf0b1eb6a60b0a55e6033b
Reviewed-on: https://chromium-review.googlesource.com/c/1377089
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Crashpad client testing no longer addresses an element of a possibly-
empty array.
Change-Id: I434b4b8c462894d8241b810973e1b4a87d1851ba
Reviewed-on: https://chromium-review.googlesource.com/c/1376375
Commit-Queue: Mark Mentovai <mark@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>
* the call to LoggingRemoveFile wrapped ina DCHECK is actually only executed in debug mode :-(
* found the issue using zxdb!
Bug: fuchsia:DX-344
Bug: crashpad:217, crashpad:196
Change-Id: I5332a17ccffd94b9bad8c61831adb797bd53a13d
Tested:`crasher` on device
Reviewed-on: https://chromium-review.googlesource.com/c/1364452
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
This code was merged from chromium commit:
6a2d5519c69e195e584055b186789b7f760c9703
Implement crashpad support for GCPW
- Implements crashpad support for GCPW installer
- Implements crashpad support for the actual credential provider dll
and runs the crashpad handler directly in the dll as an entry point
Bug: 890348
Change-Id: I5b256b4d6ad8ee7153fd22e4d13f1a1791fa6d65
Reviewed-on: https://chromium-review.googlesource.com/c/1344210
Commit-Queue: Tien Mai <tienmai@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611187}
Message-Id: Merged from chromium 6a2d5519c69e195e584055b186789b7f760c9703
Reviewed-on: https://chromium-review.googlesource.com/c/1358731
Commit-Queue: Scott Graham <scottmg@chromium.org>
we now run this code on arm64 devices in debug mode
Bug: crashpad:196
Bug: fuchsia:DX-712
Change-Id: Iea1975c5bd4cab3d503ca371ab731e25962fb255
Tested: /system/test/crashpad_tests on arm64 device in debug mode
Reviewed-on: https://chromium-review.googlesource.com/c/1352097
Commit-Queue: Francois Rousseau <frousseau@google.com>
Reviewed-by: Scott Graham <scottmg@chromium.org>
* 71d4fc is the change fixing death tests on Fuchsia where the exception was still caught by the system exception handler
* we need up to b18d39 to make Windows happy
Change-Id: Ic938caabe3dde93ebda520b389b166d78c4460a6
Reviewed-on: https://chromium-review.googlesource.com/c/1350931
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
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 ProcessSnapshotMinidump to expose a similar interface
to ModuleSnapshot::CustomMinidumpStreams(). It's implemented on the
process snapshot here because there is no way to map custom minidump
streams back to a specific module. This allows implementing tests that
inspect custom user streams in minidumps.
Bug: 896019
Change-Id: I1673c342753e13d64bddcc0083ca29fa356deac7
Reviewed-on: https://chromium-review.googlesource.com/c/1271405
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>
Remove ProcessReaderWin's ReadMemory() and ReadAvailableMemory() methods
and replace their uses with a new method that exposes an instance of
ProcessMemoryWin instead.
BUG=crashpad:262
Change-Id: Ief5b660b0504d7a740ee53c7cd2fa7672ae56249
Reviewed-on: https://chromium-review.googlesource.com/c/1278830
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Flaking like:
[ RUN ] ProcessReaderFuchsia.ChildThreads
[22244:22258:20181109,001621.809627:ERROR scoped_task_suspend.cc:44] thread failed to suspend
[22244:22258:20181109,001621.810893:WARNING process_reader_fuchsia.cc:283] zx_thread_read_state(ZX_THREAD_STATE_GENERAL_REGS): ZX_ERR_BAD_STATE (-20)
[22244:22258:20181109,001621.810937:WARNING process_reader_fuchsia.cc:295] zx_thread_read_state(ZX_THREAD_STATE_VECTOR_REGS): ZX_ERR_BAD_STATE (-20)
../../third_party/crashpad/snapshot/fuchsia/process_reader_fuchsia_test.cc:161: Failure
Expected: (threads[i].stack_regions.size()) > (0u), actual: 0 vs 0
[ FAILED ] ProcessReaderFuchsia.ChildThreads (2487 ms)
ScopedTaskSuspend appears to try relatively hard to suspend, and without
retrying indefinitely it's not clear how to do a better job. Retrying
forever isn't suitable for production code though, where it would cause
the crash reporter to hang.
Bug: fuchsia:US-553
Change-Id: Ie233d2f5578cb8c35ce47207df4f1f8d2e1152f1
Reviewed-on: https://chromium-review.googlesource.com/c/1328022
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Scott Graham <scottmg@chromium.org>
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>
This reverts commit 7f71c57a29cd9cfa719eb7730d8984aaef4adc05.
Reason for revert: Fuchsia has been transitioned to spsr.
Original change's description:
> [fuchsia] re-introduce pstate temporarily
>
> https://fuchsia.googlesource.com/garnet/+/master/bin/zxdb/client/minidump_remote_api.cc#127
> still depends on pstate and we cannot run CQ for hard transitions in Fuchsia yet
>
> Change-Id: Iea2bfc670871a8fe3f389cc54627733e6069ecbe
> Reviewed-on: https://chromium-review.googlesource.com/c/1318067
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Commit-Queue: Francois Rousseau <frousseau@google.com>
TBR=scottmg@chromium.org,frousseau@google.com
Change-Id: I5a13cab9a11b6c1262d6832e2dd5b09cad5b3740
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1321269
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Francois Rousseau <frousseau@google.com>
This is a reland of 95e97a32eba4d505ab9591e683d2147c441eea48
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Bug: crashpad:260
Change-Id: I66713de84cc26c9119e0454d19c9c189263fe054
Reviewed-on: https://chromium-review.googlesource.com/c/1318066
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@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>
* introduced in https://chromium-review.googlesource.com/c/1278829
* this blocks the rollup in Fuchsia: ../../third_party/crashpad/test/scoped_guarded_page_test.cc:30:3: error: use of undeclared identifier 'EXPECT_DEATH'
Bug: crashpad:262
Change-Id: Ifff85a63aba012533956ce494fc645b554761478
Reviewed-on: https://chromium-review.googlesource.com/c/1318313
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
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>
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>
Bug: crashpad:264
Change-Id: Ie185fbe6fe909568b7364496586fb950c074674f
Reviewed-on: https://chromium-review.googlesource.com/c/1318378
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
In the transition from Buildbot to LUCI, the Windows bots were
temporarily marked experimental. They should not be and should block the
CQ if failing.
Bug: crashpad:264
Change-Id: I781d70b323fb34209916f46c0dcf2235a95876fa
Reviewed-on: https://chromium-review.googlesource.com/c/1318386
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This reverts commit 95e97a32eba4d505ab9591e683d2147c441eea48.
Reason for revert: arm64 lto build
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
TBR=scottmg@chromium.org,jperaza@chromium.org,mark@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: crashpad:260
Change-Id: I7a2c741e6b4c10d3e3b8be3213a8ce2cd93675f7
Reviewed-on: https://chromium-review.googlesource.com/c/1316372
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
