Only partially implemented, but ProcessSnapshotMinidump now returns them
appropriately.
Bug: crashpad:10
Change-Id: I44f598256965e404f62bd93e9e2efc61527298db
Reviewed-on: https://chromium-review.googlesource.com/c/1278280
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This warning triggers reliably on most binaries and on android, spams
the logcat which may obfuscate other errors.
The actual amount varies, but is typically 40 bytes for 32-bit android
system libraries, 80 bytes for 64-bit android system libraries,
64 bytes for linux system libraries (on my machine), but so far they're
all zeroes.
Change-Id: I658434e8290c75641a3b17034ebdd958834bcd69
Reviewed-on: https://chromium-review.googlesource.com/c/1269740
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@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>
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>
In the future, Zircon's time types will change from unsigned to
signed. Use ZX_TIME_INFINITE instead of UINT64_MAX when
zx_nanosleep'ing.
See related Zircon bug ZX-2100.
Change-Id: I5eb139280c27ca817e1a489f04c860563c9b677c
Reviewed-on: https://chromium-review.googlesource.com/1123221
Commit-Queue: Nick Maniscalco <maniscalco@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@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>
On Windows (and probably elsewhere) it's possible that something else on
the system changes the memory map between when a memory snapshot range
is added to the minidump, and when the process's memory is actually read
from the target and written to the .dmp file. As a result, failing the
Read() should not result in aborting the minidump's write, which it
previously would have.
Bug: crashpad:234
Change-Id: Ib24e255a34fa2e1758621d3955ebc7a0f96166e2
Reviewed-on: https://chromium-review.googlesource.com/1096452
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Sanitization is controlled by a SanitizationInformation struct to be
read from the client's memory. The address of this struct is either
passed in a ClientInformation when the client requests a crash dump,
or as a flag to the handler --sanitization_information.
Bug: crashpad:30
Change-Id: I2744f8fb85b4fea7362b2b88faa4bef1da74e36b
Reviewed-on: https://chromium-review.googlesource.com/1083143
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
A ProcessSnapshotSanitized enables filtering possibly sensitive
information from a snapshot.
WebView has different privacy constraints than Chrome and needs to
avoid collecting data in annotations or from stack memory that may
contain PII. This CL enables:
1. Filtering annotations by name using a whitelist.
2. Filtering for crashes which reference a particular module.
3. Redacting non-essential information from stack memory.
This CL does not provide a client interface to enable sanitization.
Bug: crashpad:30
Change-Id: I8944c70fdcca6d6d4b7955d983320909bf871254
Reviewed-on: https://chromium-review.googlesource.com/1070472
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Adds the build support for using libfuzzer controlled by setting
`crashpad_use_libfuzzer=true`.
Also adds a first fuzzer (for ElfImageReader). Currently only runs on
Linux, but should work on Fuchsia too with some minor fixes (not sure
yet whether the fixes required are toolchain or in our build setup).
Run as:
out/lin/elf_image_reader_fuzzer snapshot/elf/elf_image_reader_fuzzer_corpus/
hits an OOM pretty quickly in trying to allocate a giant buffer.
Bug: crashpad:30, crashpad:196, crashpad:233
Change-Id: Idd3ca11fe00319b8b29e029d5e13b17bfd518ea0
Reviewed-on: https://chromium-review.googlesource.com/1083451
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
SimulateCrash.ChildDumpWithoutCrashing needed a larger threshold due to
ASAN instrumentation.
These tests expect children to crash, but ASAN captures the exception
before letting Crashpad handle it:
CrashpadClient.HandlerLaunchFailureCrash
CrashpadClient.HandlerLaunchFailureDumpAndCrash
CrashpadHandler.ExtensibilityCalloutsWork
ExceptionSnapshotWinTest.ChildCrash
(which is an upstreaming of https://chromium-review.googlesource.com/1067151).
Additionally, because Chrome doesn't build all, I noticed a missing
dependency on a test binary which is added here.
Bug: chromium:845011
Change-Id: I5c3ae5673512be29edad21e7d20dd57b8b5ce2bf
Reviewed-on: https://chromium-review.googlesource.com/1075715
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Change-Id: Ifcfe6c2d18045ce3a2e443ee84d4dd84bb3db373
Reviewed-on: https://chromium-review.googlesource.com/1073567
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
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>
Bug: crashpad:196
Change-Id: I82cf1c5384ebfc2fb7882e69145b211c4b24f7c5
Reviewed-on: https://chromium-review.googlesource.com/1054576
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@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>
Packaged test running seems to be a ways off, but with a bit of path
fiddling in test_paths.cc we can actually use the paths where the tests
are copied, so do that instead to get all the tests re-enabled. The
setup in BUILD.gn should be mostly-useful once packaging is working as
all helper/data files will need to specified there anyway.
Also, attempted fix to flaky behaviour in
ProcessReaderFuchsia.ChildThreads exposed because the tests are now
being run. zx_object_wait_many() waits on *any* of the objects, not
*all* of them. Derp!
And finally, for the same test, work around some unintuitive behaviour
in zx_task_suspend(), in particular that the thread will not be
suspended for the purpose of reading registers right away, but instead
only "sometime later", which appears in pratice to be after the next
context switch. Have ScopedTaskSuspend block for a while to try to
ensure the registers become readble, and if they don't, at least fail
noisily at that point.
Bug: crashpad:196
Change-Id: I01fb3590ede96301c941c2a88eba47fdbfe74ea7
Reviewed-on: https://chromium-review.googlesource.com/1053797
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
The package deployment/running is in flux at the moment. In order to get
all the other tests on to the main Fuchsia waterfall, disable the ~25
tests that require external files (for launching child processes,
loading modules, or data files) because those operations all fail on
Fuchsia-without-packages right now. Upstream this is PKG-46. Once test
packaging and running has been resolved, this can be reverted.
These tests are still run when building Crashpad standalone on Fuchsia
as the standalone build simply copies all the relevant data files to the
device in /tmp.
Bug: crashpad:196
Change-Id: I1677c394a2b9d709c59363ebeea8aff193d4c21d
Reviewed-on: https://chromium-review.googlesource.com/1045547
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Implements InitializeException() in ProcessSnapshot, and pulls it all
together writing the dump in crash handler. Sample output at crash
00163eff624e653e on the staging server.
Also adds a child-retrieve helper to koid_utilities.
Bug: crashpad:196
Change-Id: I4bee7655e81e3243ac0ae896ff0caea7ce4acdad
Reviewed-on: https://chromium-review.googlesource.com/1044771
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
- Endian-swaps the 3 integer fields of the build id when returning it
for use as the module id (see bug 229).
- Removes the "app:" prefix on the main binary, as this prevents the
crash server from matching the binary name (and it isn't particularly
useful anyway)
- Map "<vDSO>" to "libzircon.so" as that's what it actually is, so that
symbols for it can be found.
Bug: crashpad:196, crashpad:229
Change-Id: Ie4abc732b7696345b96c34dbb1a7d2cc2cfcf77f
Reviewed-on: https://chromium-review.googlesource.com/1035461
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This "child" test was actually reading itself (whoops!). Instead, pass
the address of the string to be read back from the child and read that.
Bug: crashpad:196
Change-Id: I27aa4cd06c69cd492cb3387a5a773a56e9cb02a3
Reviewed-on: https://chromium-review.googlesource.com/1033712
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Bug: 428099
Change-Id: If8818d02fd6315ad46d512357db2b70d011a52b0
Reviewed-on: https://chromium-review.googlesource.com/1031992
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: 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>
This implementation has some limitations as documented in the header,
however, threads must be suspended in order to use the register capture
debug API so this is somewhat useful for now in the context of
generate_dump.
Also, refactor some child-object retrieval helpers used in a few places.
Bug: crashpad:196
Change-Id: I1fdae5fc3d4b43841e535724eac10c1e58af04c5
Reviewed-on: https://chromium-review.googlesource.com/1007966
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This allows clients to use the database to handle uploads themselves,
e.g. on Android, where Crashpad does not yet provide an uploader.
The handler does not launch an upload thread when no url is supplied.
Previously, the handler would move these reports to
completed and record the upload as skipped with kUploadsDisabled.
With this change, these reports would remain pending until pruned,
with no metrics recorded for them in regard to their upload.
Bug: crashpad:30
Change-Id: I4167ab1531634b10e91d03229018ae6aab4103aa
Reviewed-on: https://chromium-review.googlesource.com/1010970
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
uname() seems to hang, sometimes, perhaps when then network is in a bad
state. Additionally, this way allows getting a minimal amount of version
information via zx_system_get_version().
Bug: crashpad:196
Change-Id: I2c040ee38ae017a6e8e060de10039bae6d159058
Reviewed-on: https://chromium-review.googlesource.com/1007979
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
With this `generate_dump <somepid>` generates a valid and somewhat
plausible (but still quite incomplete) minidump.
As an example, on a running Fuchsia system, `ps` reported the pid of
"netstack" as 6062, followed by `generate_dump 6062`, copy minidump.6062
to host, and run Breakpad's minidump_dump on the generated dump file,
resulting in:
https://gist.github.com/sgraham/24e4ba1af968219d7c154bb0fba43925
This looks roughly correct in that it has a bunch of threads (without
much data) and a reasonable looking module list.
Bug: crashpad:196
Change-Id: I3f68cc015f74374624a5ce497d46ac90df17a22c
Reviewed-on: https://chromium-review.googlesource.com/1005978
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
- Implement ProcessID().
- Return empty ProcessStartTime() and ProcessCPUTimes() as there's
nothing available.
- Return the Threads that were collected in Initialize().
- Return empty MachineDescription() plus upstream bug link.
Bug: crashpad:196
Change-Id: I77b33c18ed3844464bb5b9f238406191c221b17e
Reviewed-on: https://chromium-review.googlesource.com/1005889
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Mostly sensible implementation for x64 via cpuid. It's too early for
Fuchsia to have a version number, so nothing is reported for those
fields. ARM64 isn't implemented at all and would hit a lot of
NOTREACHED()s.
Bug: crashpad:196
Change-Id: I6ca8b12e16fe0cf773a17c88ca9d407b028a501c
Reviewed-on: https://chromium-review.googlesource.com/1005906
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>
The crashpad_{executable, loadable_module} templates won't have
pre-existing configs lists to modify. Use configs and remove_configs
to merge changes into default configs when using the templates.
Change-Id: Id7c0b1991c9d0ac55022b427feb59df28668b959
Reviewed-on: https://chromium-review.googlesource.com/981778
Reviewed-by: Mark Mentovai <mark@chromium.org>
When building in chromium, executables and loadable_modules should
depend on:
//build/config:exe_and_shlib_deps
which, among other things, may be needed to introduce a
dependency on a custom libc++.
Bug: crashpad:30
Change-Id: Ic46a3cf5b46bdac09cca22950f9236e0776ba44a
Reviewed-on: https://chromium-review.googlesource.com/974713
Reviewed-by: Mark Mentovai <mark@chromium.org>
Don't attempt to read data if the note isn't in an allocated segment.
See investigation starting at
https://bugs.chromium.org/p/crashpad/issues/detail?id=220#c27 for
details.
Bug: crashpad:220, crashpad:30, crashpad:196
Change-Id: I60eaacb83ad00ef33bde9079d25cc23a59bdf2c8
Reviewed-on: https://chromium-review.googlesource.com/941507
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This is mostly empty except for the ID, until I concoct a way to get the
stack out of Fuchsia, and implement context capture.
Bug: crashpad:196
Change-Id: I26d0622d44aefba88750f7ec6feb1a6e95467208
Reviewed-on: https://chromium-review.googlesource.com/932941
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This fills out Threads() in ProcessReader, gathering some information
for which there's system calls, and adds some basic tests for
ProcessReader on Fuchsia.
Bug: crashpad:196
Change-Id: I0738e77121c90a8b883267c1df0fcfc6621674d7
Reviewed-on: https://chromium-review.googlesource.com/929350
Commit-Queue: Scott Graham <scottmg@chromium.org>
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>
And document that UnloadedModules() isn't applicable on Fuchsia.
Bug: crashpad:196
Change-Id: Ic2c5f26fbc9cbd908ec0b941797c63f88caeec9c
Reviewed-on: https://chromium-review.googlesource.com/929302
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>
Includes mini_chromium DEPS roll of one change:
4e3b2c0 fuchsia: Make target flag apply to asm too
After this, the Fuchsia ARM64 build compiles.
Bug: crashpad:196
Change-Id: I1b749a2b2443303ad86122fbe5c9750300474d79
Reviewed-on: https://chromium-review.googlesource.com/925454
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
These tests needed to be updated to expose CrashpadInfo in the same way
as the main CrashpadInfo g_crashpad_info is found on
Linux/Android/Fuchsia.
Unfortunately, while the tests pass on Fuchsia when run in isolation,
the implementation of dlclose() on Fuchsia currently does nothing. So,
if the full test suite is run, there's interference between the test
modules (i.e. the values in _small vs. the values in _large), so the
tests fail.
I filed ZX-1728 upstream about this to see if it might be implemented,
or if the test will need to spawn a clean child to do the module load
tests in.
Bug: crashpad:196
Change-Id: I9ee01b142a29c508c6967dc83da824afa254d379
Reviewed-on: https://chromium-review.googlesource.com/923182
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
In preference to (the reverted)
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/923178
this does not share implementation with the tests in
snapshot/crashpad_info_client_options_test.cc. This is not done because
those tests use faked CrashpadInfo structures that are intentionally
differently sized than the current defintion of CrashpadInfo, meaning
that the scoped reset could overwrite past the end of the structure.
Not resetting these was causing CrashpadInfoClientOptions tests to fail
on Fuchsia, because dlclose() [legally] doesn't do anything, so
modifying the current binaries CrashpadInfo caused the expected values
from child .sos to be ignored. That could be worked around in that test
too, but it's probably better to clean up the global state in this test
anyway.
Bug: crashpad:196
Change-Id: Ia3f81f1d5872b5ef7d543fcc68b56af4c0b6ca0a
Reviewed-on: https://chromium-review.googlesource.com/923561
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This reverts commit 4717300fa4cefadeabef64346ba65aa8759d43b8.
Reason for revert: When used in with the size-testing fake CrashpadInfo's, this can overwrite past the end of them.
Original change's description:
> Reset CrashpadInfo after CrashpadInfoReader tests
>
> Not resetting these was causing CrashpadInfoClientOptions tests to fail
> on Fuchsia, because dlclose() [legally] doesn't do anything, so
> modifying the current binaries CrashpadInfo caused the expected values
> from child .sos to be ignored. That could be worked around in that test
> too, but it's probably better to clean up the global state in this test
> anyway.
>
> Bug: crashpad:196
> Change-Id: Ia8119ac7c554bea81e8373e2547faf192c629122
> Reviewed-on: https://chromium-review.googlesource.com/923178
> Commit-Queue: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Joshua Peraza <jperaza@chromium.org>
TBR=scottmg@chromium.org,jperaza@chromium.org
Change-Id: Ia6d8db1ba24c82bb9346210ac8b66d80f42a6925
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: crashpad:196
Reviewed-on: https://chromium-review.googlesource.com/923541
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Not resetting these was causing CrashpadInfoClientOptions tests to fail
on Fuchsia, because dlclose() [legally] doesn't do anything, so
modifying the current binaries CrashpadInfo caused the expected values
from child .sos to be ignored. That could be worked around in that test
too, but it's probably better to clean up the global state in this test
anyway.
Bug: crashpad:196
Change-Id: Ia8119ac7c554bea81e8373e2547faf192c629122
Reviewed-on: https://chromium-review.googlesource.com/923178
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
In trying to clear out the end of info when the alleged size is smaller
than the current structure size, we didn't handle the opposite case. We
need to continue the rest of Read() to initialize members, but need to
make sure not to pass a very large (negative -> size_t) length to
memset().
Additionally, I believe it meant to memset from the end of the alleged
size, to the end of the local structure, rather than from the beginning
of the structure.
This repro'd on Fuchsia, but would affect all platforms that use it.
Bug: crashpad:196, crashpad:30
Change-Id: I9c35c834010b5cb26d54156ce8f9bc538dcbf96c
Reviewed-on: https://chromium-review.googlesource.com/923094
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@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>
Adds beginning ProcessReader implementation for Fuchsia which currently
only reads modules from the target process. ModuleSnapshotFuchsia
implemented enough to pull out CrashpadInfo, which in turn is passed
through ProcessSnapshotFuchsia, which is enough to get
CrashpadInfoClientOptions.OneModule to pass.
Bug: crashpad:196
Change-Id: I92b82696c464a5ba2e0db2c75aa46fd74b0fa364
Reviewed-on: https://chromium-review.googlesource.com/910324
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@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>
Previously, the mac version was under client/ and win under util/win/.
This cl brings them all together under util/misc/ and combines common
test code.
Bug: crashpad:30
Change-Id: Idf0d0158b969d5aa9802dfc8c21f73041b2bcc6c
Reviewed-on: https://chromium-review.googlesource.com/907755
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
In setting up the gn build, slightly different optimization settings
were applied for release builds. This caused a couple things to happen,
1) the sketchy noinline declspec was ignored, and 2) the distance
between reading the IP and the actual crash exceeded the tolerance of 64
bytes in the parent.
To make the test more robust to this, use CaptureContext() (I think our
improved version didn't exist at the time the tests was originally
written). Also, switch from crashpad::CheckedWriteFile to Windows'
WriteFile(), which avoids inlining a whole lot of code at that point.
The return value is not checked, but the next thing that happens is that
the function crashes unconditionally, so this does not seem like a huge
problem.
Bug: crashpad:79
Change-Id: I8193d8ce8b01e1533c16b207813c36d6d6113d89
Reviewed-on: https://chromium-review.googlesource.com/902693
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
kDoesNotObserveDaylightSavingTime can indicate only that the
standard/daylight transition is not automatic, as opposed to it not
existing at all.
Bug: crashpad:214
Change-Id: Ib7016806e79465a6dde605dd667b75a802e1b6c5
Reviewed-on: https://chromium-review.googlesource.com/904767
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
- default to subsystem:console
- don't build posix/timezone.*
- add some missing libs
This gets all the main binaries building and running. Most configs pass,
but there's some offsets that seem different in some builds; need to
investigate more. Additionally, the binaries used by end_to_end_test.py
aren't yet built, so that script fails.
Includes mini_chromium roll to 46eeaf9:
46eea49 gn win: Add debug info and pdb to cc/cxx
902a29f gn win: Various fixes towards making GN build work
Bug: crashpad:79
Change-Id: Ie56a469b84bed7b0330172cec9f1a8aeb95f702e
Reviewed-on: https://chromium-review.googlesource.com/902403
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Fix Windows- and Mac-in-Chromium GN builds.
Bug: crashpad:79
Change-Id: I952f364ed679a13f656a8db18fb4d1fbf5858c17
Reviewed-on: https://chromium-review.googlesource.com/900206
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@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>
Avoid fork() so that the tests can work on Fuchsia. Fills out
CrashpadInfo in the child, and then sends the addresses of various
structures to the parent process to be used for expectation checking.
Bug: crashpad:196, crashpad:215
Change-Id: I9ace6671d2e9184d48fe33016a01271ccfbcbfb6
Reviewed-on: https://chromium-review.googlesource.com/894705
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Without the section headers for the symbol table, there's no direct way
to calculate the number of entries in the table.
DT_HASH and DT_GNU_HASH are auxiliary tables that are designed to make
symbol lookup faster. DT_HASH is the original and is theoretically
mandatory. DT_GNU_HASH is the new-and-improved, but is more complex.
In practice, however, an Android build (at least vs. API 16) has only
DT_HASH, and not DT_GNU_HASH, and a Fuchsia build has only DT_GNU_HASH
but not DT_HASH. So, both are tried.
This change does not actually use the data in these tables to improve
the speed of symbol lookup, but instead only uses them to correctly
terminate the linear search.
DT_HASH contains the total number of symbols in the symbol table fairly
directly because there is an entry for each symbol table entry in the
hash table, so the number is the same.
DT_GNU_HASH regrettably does not. Instead, it's necessary to walk the
buckets and chain structure to find the largest entry.
DT_GNU_HASH doesn't appear in any "real" documentation that I'm aware
of, other than the binutils code (at least as far as I know). Some
more-and-less-useful references:
- https://flapenguin.me/2017/04/24/elf-lookup-dt-hash/
- https://flapenguin.me/2017/05/10/elf-lookup-dt-gnu-hash/
- http://deroko.phearless.org/dt_gnu_hash.txt
- https://sourceware.org/ml/binutils/2006-10/msg00377.html
Change-Id: I7cfc4372f29efc37446f0931d22a1f790e44076f
Bug: crashpad:213, crashpad:196
Reviewed-on: https://chromium-review.googlesource.com/876879
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Switches from test::Multiprocess to test::MultiprocessExec for
ElfImageReader.OneModuleChild.
Uses the new child process launching, and passes the address of libc and
the address of getpid from the child to parent, rather than assuming the
values will be the same in both processes.
And, enables the test on Fuchsia since it now works.
Bug: crashpad:196, crashpad:215
Change-Id: I3650c16c4fccfe9c1e4147192fdc88b997460060
Reviewed-on: https://chromium-review.googlesource.com/887373
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Switches from test::Multiprocess to test::MultiprocessExec for
ElfImageReader.MainExecutableChild.
Uses the new child process launching, and passes the expected symbol
address from the child to the parent, rather than assuming the value
will be the same in both processes.
And, enables the test on Fuchsia since it now works.
Bug: crashpad:196, crashpad:215
Change-Id: I3b43407b6584275d61bedc9c13d1625b950fc23b
Reviewed-on: https://chromium-review.googlesource.com/884993
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Change-Id: I062c853d65c3e89a61920d790d9bc5c993b46fcd
Reviewed-on: https://chromium-review.googlesource.com/884581
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
(Still need to avoid fork()-dependence for the non-self tests.)
Bug: crashpad:196
Change-Id: Ib34fe33c7ec295881c1f555995072d9ff742647f
Reviewed-on: https://chromium-review.googlesource.com/876650
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Bug: crashpad:196
Change-Id: Ia9bcc45891fd5cf40cccc655c4b904b1610e5932
Reviewed-on: https://chromium-review.googlesource.com/875117
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>
The in-Fuchsia build fails with:
../../third_party/crashpad/snapshot/crashpad_info_size_test_module.cc:89:77: error: missing field 'indirectly_referenced_memory_cap_' initializer [-Werror,-Wmissing-field-initializers]
TestCrashpadInfo g_test_crashpad_info = {'CPad', sizeof(TestCrashpadInfo), 1};
kulakowski mentioned in the context of the = {0} CL recently that
they've turned on some somewhat unusual warnings because they have a
higher-than-usual amount of C code, as well as code that has to build as
both C and C++. I think that's where this one comes from.
Bug: crashpad:196
Change-Id: Ie1b373a32f99615366c7fcd65cd4ae4761385ff9
Reviewed-on: https://chromium-review.googlesource.com/862802
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
The dynamic array reader should treat data as unsigned when initially
reading values from the array to prevent premature sign-extension. The
glibc and traditional android headers define d_val using Elf32_Word, an
unsigned type. linux/elf.h, used by unified android headers, defines
d_val using Elf32_Sword, a signed type. Use d_ptr instead since it's
always an unsigned type.
Bug: crashpad:30
Change-Id: Ie8e88941fefc7075621aefe226fdba33b1f6129c
Reviewed-on: https://chromium-review.googlesource.com/847818
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
With a companion mini_chromium change at https://crrev.com/c/841203,
it’s possible to configure via “gn args” as follows:
android_ndk = "/android/android-ndk-r16"
target_cpu = "x86_64"
target_os = "android"
Note that a standalone toolchain is not required.
Bug: crashpad:30, crashpad:79
Change-Id: Ica55bdcb82c730909c05dd9fecb40a74eca78c8a
Reviewed-on: https://chromium-review.googlesource.com/841286
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Bug: crashpad:79
Change-Id: I417f17194ee1a8ef157ea1e67e64878ccb6f5c10
Reviewed-on: https://chromium-review.googlesource.com/835528
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
