On iOS, holding a lock during a slow upload can lead to watchdog kills
if the app is suspended mid-upload. Instead, if the client can obtain
the lock, the database sets a lock-time file attribute and releases the
flock. The file attribute is cleared when the upload is completed. The
lock-time attribute can be used to prevent file access from other
processes, or to discard reports that likely were terminated mid-upload.
Bug:chromium:1342051
Change-Id: Ib878f6ade8eae467ee39acb52288296759c84582
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3739019
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Adds a new IOSIntermediateDumpWriter::AddPropertyCString method which
takes an address to a cstring of unknown length and page-by-page
searches for a NUL-byte terminator.
This is necessary because currently WriteModuleInfo calls strlen
directly on the dyld and module filePath without first using vm_read.
On iOS14 this occasionally crashes, and is generally unwise. Instead,
use AddPropertyCString.
This patch also removes WriteDyldErrorStringAnnotation, as it's no
longer used going forward with iOS 15.
Bug: 1332862
Change-Id: I3801693bc39259a0127e5175dccf286a1cd97ba7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3689516
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
GCC does not allow binding a packed field to an address. Assign
to a intermediate variable instead before pushing to map.
Bug: chromium:819294
Change-Id: I806e5f99c2b19e656b91a60f72172b59c961ba5f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3751392
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This adds a runtime exception helper (& test module) for Windows and
plumbing to allow the module to be registered by the crashpad client,
and to trigger the crashpad handler. Embedders can build their own
module to control which exceptions are passed to the handler.
See: go/chrome-windows-runtime-exception-helper for motivation.
When registered (which is the responsibility of the embedding
application), the helper is loaded by WerFault.exe when Windows
Error Reporting receives crashes that are not caught by crashpad's
normal handlers - for instance a control-flow violation when a
module is compiled with /guard:cf.
Registration:
The embedder must arrange for the full path to the helper to
be added in the appropriate Windows Error Reporting\
RuntimeExceptionHelperModules registry key.
Once an embedder's crashpad client is connected to a crashpad
handler (e.g. through SetIpcPipeName()) the embedder calls
RegisterWerModule. Internally, this registration includes handles
used to trigger the crashpad handler, an area reserved to hold an
exception and context, and structures needed by the crashpad handler.
Following a crash:
WerFault.exe handles the crash then validates and loads the helper
module. WER hands the helper module a handle to the crashing target
process and copies of the exception and context for the faulting thread.
The helper then copies out the client's registration data and
duplicates handles to the crashpad handler, then fills back the various structures in the paused client that the crashpad handler will need.
The helper then signals the crashpad handler, which collects a dump then
notifies the helper that it is done.
Support:
WerRegisterExceptionHelperModule has been availble since at least
Windows 7 but WerFault would not pass on the exceptions that crashpad
could not already handle. This changed in Windows 10 20H1 (19041),
which supports HKCU and HKLM registrations, and passes in more types of
crashes. It is harmless to register the module for earlier versions
of Windows as it simply won't be loaded by WerFault.exe.
Tests:
snapshot/win/end_to_end_test.py has been refactored slightly to
group crash generation and output validation in main() by breaking
up RunTests into smaller functions.
As the module works by being loaded in WerFault.exe it is tested
in end_to_end_test.py.
Bug: crashpad:133, 866033, 865632
Change-Id: Id668bd15a510a24c79753e1bb03e9456f41a9780
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3677284
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Changes copied verbatim from Chromium with one exception to remove
Chromium specific gn args.
This includes a mini_chromium roll to not codesign within Xcode.
Change-Id: I89b35bee08f9bc9e37f902f2b57e02acb2113ae1
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3726509
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Windows 7 doesn't support SetThreadDescription/GetThreadDescription. Add
an IsSupported to ScopedSetThreadName test to wrap unsupported calls.
Change-Id: I70d4e20b94efea03e41c5f7ed8d8e1b886192923
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3722556
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is a reland of 460943dd9a71dc76f68182a8ede766d5543e5341
Original change's description:
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
The reland isolates the change to non-Android POSIX systems because
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
Change-Id: If44629f5445bb0e3d0a1d3698b85f047d1cbf04f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3721655
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This reverts commit 460943dd9a71dc76f68182a8ede766d5543e5341.
Reason for revert: This fails to compile in Chromium Android.
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
https://ci.chromium.org/ui/p/chromium/builders/try/android_compile_dbg/1179765/overview
Original change's description:
> posix: Replace DoubleForkAndExec() with ForkAndSpawn()
>
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
>
> Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Mark Mentovai <mark@chromium.org>
Change-Id: I7f6161bc4734c50308438cdde1e193023ee9bfb8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3719439
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This fixes a test case that accesses settings for the first time in
multiple threads simultaneously.
Fixed: crashpad:417
Change-Id: I6539682f171563f8ff5a1203fdd550ab92afc276
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3711807
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The DoubleForkAndExec() function was taking over 622 milliseconds to run
on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
some custom traces and found that the fork() syscall is the bottleneck
here, i.e., the first fork() takes around 359 milliseconds and the
nested fork() takes around 263 milliseconds. Replacing the nested fork()
and exec() with posix_spawn() reduces the time consumption to 257
milliseconds!
See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
slow on macOS and why posix_spawn() is a better replacement.
Another point to note is that even base::LaunchProcess() from Chromium
calls posix_spawnp() on macOS -
8f8d82dea0:base/process/launch_mac.cc;l=295-296
Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
clang-format doesn’t work after week’s buildtools update to 0a14d52dad27
without separately checking out buildtools/clang_format/script.
Change-Id: I8330aacb85d1ba96318e5f2cd4563b6d32615963
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3707851
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Importing Crashpad into Chromium revealed a few build failures:
1) The MSVC compiler needed assistance constructing SleepingThreads
2) scoped_set_thread_name_posix.cc did not build on Android, where
BUILDFLAG(IS_LINUX) is not defined and __ANDROID_API__ must be
set to 24 or higher to use pthread_getname_np()
This fixes the build failures, which I tested with a Chromium CQ
dry-run:
https://crrev.com/c/3703491
Change-Id: Ibde7cacaa45d384272890ea9b1ee2d707048ab03
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3703446
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The Chromium presubmits flagged a missing #include in
process_reader_win_test.cc. This adds the missing #include.
Change-Id: I68aed4328f976bba547a0cb7a9ea833fdf71873b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3703312
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Fuchsia's Crashpad roller was broken due to uninitialized fields in
structs.
Bug: fxbug.dev/101498
Change-Id: I1283afea9c5ac4eddb432590f9a5ec5cb1856a7c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3704517
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alex Pankhurst <pankhurst@google.com>
Sanitizers can prevent the installation of signal handlers, but
sigaction would still return 0 (for success). Detect this by checking
the installed signal handler via a second call to sigaction.
R=mark@chromium.org
Bug: chromium:1328749
Change-Id: I62a5777379ec5c6b1ca2d5a62e7cd3fb8ed1437b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3702302
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Clemens Backes <clemensb@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>
This updates buildtools to 8b16338d17cd. gn has migrated out of
buildtools and into its own cipd package, so gn is pulled at
2ecd43a10266 (current). This provides a mac-x86_64 or mac-arm64 gn as
appropriate for the host CPU architecture. The buildtools update also
brings distinct clang-format executables for mac-x86_64 and mac-arm64 as
appropriate.
Change-Id: I4162b093cfe8d5a2ba66ba62f6462813ea489dbd
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3700190
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
https://crrev.com/c/3671775/ introduced a warning (and thus, a
compilation failure) on 32-bit ARM when taking the address of the RVA64
field MINIDUMP_THREAD_NAME::RvaOfThreadName:
minidump/minidump_thread_name_list_writer.cc:57:23: error: taking address of packed member 'RvaOfThreadName' of class or structure 'MINIDUMP_THREAD_NAME' may result in an unaligned pointer value [-Werror,-Waddress-of-packed-member]
name_->RegisterRVA(&thread_name_.RvaOfThreadName);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Indeed, MINIDUMP_THREAD_NAME's RvaOfThreadName field is not aligned,
so the technique used in MinidumpWritable::Register*() of passing in a
rawptr to an arbitrary struct field which is later dereferenced cannot
be used for this field.
This CL replaces the use of MinidumpWritable::Register*() with
overriding MinidumpThreadNameWriter::WillWriteAtOffsetImpl() to
directly calculate and assign thread_name_.RvaOfThreadName.
Change-Id: I71e751a5b5e896b5e7277879bdbdff6e9eefe023
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3693846
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Ben Hamilton <benhamilton@google.com>
The minidump stream type MINIDUMP_THREAD_NAME_LIST represents
thread names as a list in the form [(thread_id, thread name), ...].
This introduces a new MinidumpThreadNameListWriter class which
allows OS-specific snapshot writers to write thread names using
this new stream type.
Bug: crashpad:327
Change-Id: Ief45df5dbbf44c0e1254786bfbe6720112ceef38
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3671775
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
To support MINIDUMP_THREAD_NAME_LIST (which uses 64-bit RVAs for the
thread name MINIDUMP_STRING), this adds minidump string writing and
reading support for the new 64-bit RVA64 and
MINIDUMP_LOCATION_DESCRIPTOR64 types.
Bug: crashpad:327
Change-Id: Iffefffef358517dfc6deac02051dff9dbb8eb214
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3673779
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Fuchsia's Crashpad roller was failing due to 'std::size' not being found
and struct fields not being initialized (detected by
-Wmissing-field-initializers)
- Fix 'std::size' issue by using a std::array instead of a plain C array
- Fix missing initializers with default values
Bug: fxbug.dev/101498
Change-Id: I75fa54d5c1730772b1af1be31c64b0cc58886a90
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3687239
Commit-Queue: Alex Pankhurst <pankhurst@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Newer minidump stream types, like MINIDUMP_THREAD_NAME_LIST, use
64-bit RVAs (which have 64-bit location descriptors) instead of 32-bit
RVAs and location descriptors.
This adds support to MinidumpWritable for the new 64-bit RVA64 and
MINIDUMP_LOCATION_DESCRIPTOR64 types.
Bug: crashpad:327
Change-Id: Icd67bca600756a68ef9ba7d5a429f935eebf726f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3673776
Commit-Queue: Ben Hamilton <benhamilton@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
There were two shutdown races in the iOS Crashpad client:
1) MachMessageServer::Run can return either MACH_RCV_PORT_CHANGED *or*
MACH_RCV_INVALID_NAME based on the timing of when the port is
closed, for example:
c21f7bab5c/Sources/CwlPreconditionTesting/CwlCatchBadInstruction.swift (L131)
2) The iOS crashpad::CrashHandler thread could read from its member
variable mach_handler_running_ while another thread wrote to it
Change-Id: I696ece8575d9b88cbd0593e7c479bd4c7f863f45
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3651395
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
* ATOMIC_FLAG_INIT is deprecated.
* Compound ops on volatiles are deprecated.
Bug: chromium:1284275
Change-Id: I2235662c00e4be8c5eba2aaf565663faf8d9576a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3658639
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Crashpad annotation names are currently limited to 64 bytes.
Breakpad supports up to 256 bytes, so for compatibility with existing
clients, this increases the maximum annotation name size from 64 to
256 and adds new tests to confirm the maximum name and value sizes.
Change-Id: Ib7954bea96046b6b7e18ed9743fe2a15dd3dabac
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3655975
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
IOSIntermediateDumpWriter::Close() is intended to close the FD opened
by the in-process handler.
Currently, InProcessHandler::ScopedLockedWriter::~ScopedLockedWriter() does invoke IOSIntermediateDumpWriter::Close().
However, InProcessHandler::Initialize() invokes the utility CreateWriterWithPath() which directly creates an IOSIntermediateDumpWriter. It neither uses ScopedLockedWriter nor invokes Close().
This fixes the issue by:
1) Making IOSIntermediateDumpWriter::~IOSIntermediateDumpWriter() DCHECK() that it's closed
2) Calling IOSIntermediateDumpWriter::Close() from InProcessHandler::~InProcessHandler() and from test files
Change-Id: Ibfede0a3d2aeac948c7ff3d56445e13d1a4028b5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3648710
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Some xstate flags are not available in arm64 as it does not have
xstate so we should omit the InitializeXState method on the
`target_cpu = arm64` configuration.
Bug: 1250098
Change-Id: I5c92d6efbe90587bdebef87d4a6ce4e9b25afa4d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3653575
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
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>
Adds new structures and offsets for minidump extended contexts. This
information will be captured from threads in a later CL so this CL
does not yet write different dumps, except in testing.
Minidump format for extended compacted contexts has been determined by
experiment. Offsets for where to write various parts of the context
are hardcoded to 0x550 as this matches values seen in Windows. Offsets
for misc_info_5 match those seen in working minidumps that can be opened
in windbg. Our hope is that while these could change in future, CPU
and OS vendors are unlikely to change them.
See doc[0] for a discussion of these fields and offsets in the minidump.
See "MANAGING STATE USING THE XSAVE FEATURE SET" Chapter 13 in the
Intel SDM[1]. 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"[2].
[0] https://docs.google.com/document/d/1Dn8n97r5B7kxYouvujNnPIYd_7QeVHpahSRmB92Qn6g/edit#heading=h.hivqj2jg39y
[1] 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.
[2] https://www.amd.com/system/files/TechDocs/24593.pdf
Bug: 1250098
Change-Id: Ia9041acc379c6d38329ee99737a2a0a77f7a1ee0
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3536964
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
This will be used in a later CL to shuttle shadow stack information
from capture to minidumps. For now these fields are zeroed and have
no effect on any platform.
The x64 snapshot context we use no longer directly maps to the early
CONTEXT structure used by Windows (the prelude still matches). This
may cause confusion if people use the size of a snapshot context when
they meant to use sizeof(CONTEXT).
Bug: 1250098
Change-Id: Idac7d888b9e606ceb250c4027e0e7f29f4c0a55f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3536963
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>
It seems on iOS 14, sometimes this path can be empty. Passing nullptr
to strlen will crash. Also fixes an incorrect file path length for
the dyldPath.
Bug: 1323905
Change-Id: Idf1ef9e0165853a5d57d272896a40bf0b30a3368
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3637717
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This brings Crashpad in line with what Breakpad captures.
Change-Id: I8ce2d81fc9cb150dc9817034fac3516f27f5661b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3611069
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
It is not safe to start the upload thread when in the background (due
to the potential for flocked files in shared containers).
Bug: 1317812
Change-Id: Ie476c2ccbc7232bc9e1a30a7a497128a4248c39e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3595621
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Followup to crrev.com/c/3573184, which did not honor destructor order,
leading to the background task releasing before the lock.
Bug: 1313555
Change-Id: Ifbd3902964552458b83cfc550f50058067021499
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3591012
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
In a later CL, in some cases these structs were not zero-initialized
which caused some iOS tests to fail.
We now zero-initialize these structs which should be harmless now,
and useful later.
Bug: 1250098
Change-Id: I933e80e56714a1d8988deae3aa56ec36ed98ef03
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3538665
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Because the upload thread uses synchronous upload, calling Stop() on
that thread from the main thread will lock, and trigger a terminate
when transitioning from foreground to background.
Additionally, background assertions now only last 30 seconds, so
shorten the timeout to 20 seconds.
This is a followup to https://crrev.com/c/3517967.
Bug: crashpad:1315441
Change-Id: Ic6886607805667ffce5ecf41716fc63333a341b8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3577820
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Use ScopedBackgroundTask to prevent file lock termination from happening
when holding locked files in a shared AppGroup.
Bug: 1313555
Change-Id: Idc0105f8ecdb65c26214a7265a216b9d480ed01d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3573184
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
