sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This CL adds a new method ThreadSnapshot::ThreadName(), implements
it in each snapshot implementation, and adds tests for iOS, macOS,
Linux, Windows, and Fuchsia.
Bug: crashpad:327
Change-Id: I35031975223854c19d977e057dd026a40d33fd41
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3671776
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Ben Hamilton <benhamilton@google.com>
Windows extended contexts must be allocated by InitializeContext2 and
may not be aligned. This means we cannot simply store a struct in
our thread snapshot object, but must instead store enough memory
and alias our struct onto this backing memory.
Note that shadow stack pointers are not yet recorded for the initial
exception - this cannot be determined using LocateXStateFeature in
the capturing process and will be added in a future CL by plumbing
through client messages when a crashed process requests a dump.
See crash/32bd2c53a252705c for an example dump with this baked into
chrome, that has passed through breakpad without breaking it. Local
testing shows this creates valid dumps when built into Chrome, but
that the referenced memory limits may need to be increased to allow
for ssp referenced memory to be included.
See "MANAGING STATE USING THE XSAVE FEATURE SET" Chapter 13 in the
Intel SDM[0]. Many of the offsets and sizes of the extended features
are provided by cpu specific values. We can access these in Windows
using the SDK, and transfer these to the saved extended context
which in turn is understandable by windbg.
Further information is available from AMD Ch. 18 "Shadow Stacks"[1].
[0] https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-sdm-combined-volumes-1-2a-2b-2c-2d-3a-3b-3c-3d-and-4.html.
[1] https://www.amd.com/system/files/TechDocs/24593.pdf
Bug: 1250098
Change-Id: I4b13bcb023e9d5fba257044abfd7e251d66a9329
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3300992
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
In a future CL we will make use of InitializeContext2 which can produce
contexts of varying sizes - this makes the existing use of a union for
wow/x64 contexts no longer feasible.
The context union in process_reader_win is replaced with a (moveable,
copyable) helper struct which currently only knows how to allocate
the replaced WOW or CONTEXT sized unions.
As this field is no longer a member of the Thread struct it cannot
be passed into other functions as a reference, so instead a pointer
is used in these functions.
Bug: 1250098
Change-Id: Ied3fe971c0073bbdafc071217e1bb0f72350bb4e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3538668
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
If the file just needs the CHECK/CHECK_OP/NOTREACHED
macros, use the appropriate header for that instead.
Or if logging.h is not needed at all, remove it.
This is both a nice cleanup (logging.h is a big header,
and including it unnecessarily has compile-time costs),
and part of the final step towards making logging.h no
longer include check.h and the others.
Bug: chromium:1031540
Change-Id: Ia46806bd95fe498bcf3cf6d2c13ffa4081678043
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2255361
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
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>
Remove stl_util from Crashpad. This also updates mini_chromium to
4f3cfc8e7c2b7d77f94f41a32c3ec84a6920f05d to remove stl_util from there
as well.
4f3cfc8e7c2b Remove stl_util from mini_chromium
BUG=chromium:555865
Change-Id: I8ecb1639a258dd233d524834ed205a4fcc641bac
Reviewed-on: https://chromium-review.googlesource.com/438865
Reviewed-by: Scott Graham <scottmg@chromium.org>
Add a user-configurable cap on the amount of memory that is gathered by
dereferencing thread stacks. (SyzyAsan stores a tremendously large
number of pointers on the stack, so the dumps were ending up in the ~25M
range.)
Also reduce the range around pointers somewhat.
Change-Id: I6bce57d86bd2f6a796e1580c530909e089ec00ed
Reviewed-on: https://chromium-review.googlesource.com/338463
Reviewed-by: Mark Mentovai <mark@chromium.org>
Removes the bitness-specific targets in favour of pulling binaries from
the other build directory. This is to avoid the added complexity of
duplicating all the targets for the x86 in x64 build.
Overall, mostly templatizing more functions to support the
wow64-flavoured structures. The only additional functionality required
is reading the x86 TEB that's chained from the x64 TEB when running
as WOW64.
The crashing child test was switched to a manual CreateProcess because
it needs to launch a binary other than itself.
R=mark@chromium.org
BUG=crashpad:50
Review URL: https://codereview.chromium.org/1349313003 .
A few function implementations that were missing, various switches
for functions/functionality that didn't exist on XP, and far too long
figuring out what exactly was wrong with SYSTEM_PROCESS_INFORMATION
on x86 (the "alignment_for_x86" fields).
R=mark@chromium.org
BUG=crashpad:1, crashpad:50, chromium:531663
Review URL: https://codereview.chromium.org/1336823002 .
Retrieve context and save to thread context. NtQueryInformationThread
is no longer required (right now?) because to retrieve the CONTEXT, the
thread needs to be Suspend/ResumeThread'd anyway, and the return value
of SuspendThread is the previous SuspendCount.
I haven't handle the x86 case yet -- that would ideally be via
Wow64GetThreadContext (I think) but unfortunately that's Vista+, so I'll
likely need to to a bit of fiddling to get that sorted out. (It's actually
likely going to be NtQueryInformationThread again, but one thing at a
time for now.)
R=cpu@chromium.org, rsesek@chromium.orgTBR=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1133203002
The next big piece of functionality in snapshot. There's a bit more
grubbing around in the NT internals than would be nice, and it has
made me start to question the value avoiding MinidumpWriteDump. But
this seems to extract most of the data we need (I haven't pulled
the cpu context yet, but I hope that won't be too hard.)
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1131473005
