This GN arg config repros the failure in the bug:
```
chrome_pgo_phase = 1
is_official_build = true
target_cpu = "arm64"
target_os = "android"
use_remoteexec = true
```
Commenting out either is_official_build or chrome_pgo_phase removes the
compile error, but since many bots build with is_official_build, the
culprit must be chrome_pgo_phase.
Bug: chromium:362787700
Change-Id: I536a098693b85ed93c22e38e639b393fcb480e79
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5826154
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
`DISABLE_CFI_ICALL` is already defined in that header; use it.
This is both simpler and less likely to trigger macro redefinition
errors.
This was previously landed in crrev.com/c/5805458, but reverted due to
crbug.com/362787700.
Bug: chromium:362787700
Change-Id: I1fc8d9dc0b099c67ea7d774034b7691691ff2a50
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5825328
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This was tested locally by adding "-Wunreachable-code-aggressive" after
making NOTREACHED() [[noreturn]] in mini_chromium and then getting that
to compile.
Bug: chromium:40580068
Change-Id: I7ec1c72be1d73436d128660a621e9060eaebaee8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5780891
Reviewed-by: Mark Mentovai <mark@chromium.org>
This was generated by replacing " NOTREACHED()" with
" NOTREACHED_IN_MIGRATION()" and running git cl format.
This prepares for making NOTREACHED() [[noreturn]] alongside
NotReachedIsFatal migration of existing inventory.
Bug: chromium:40580068
Change-Id: Idb68e2fc8adba180350b0595fd494cf0f206bded
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5548246
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Bug: crashpad: 326459659,326458942,326459376,326459390,326459417,326458979,326459333,326459016,326458338,326458738,326459156,326459512,326458694
Change-Id: I04724530cbef50a8d3c18f306d16c0bbf3b0815b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/5512394
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Arthur Wang <wuwang@chromium.org>
These are slightly frustrating. First, when a struct is packed, some of
its fields may be underaligned. This is fine for direct access
(foo.bar), but if one takes the address if the field, this creates an
unaligned pointer. Dereferencing that pointer is then UB. (I'm not sure
if creating that pointer is UB.)
Crashpad seemingly doesn't do this, but it uses EXPECT_EQ from GTest.
EXPECT_EQ seems to internally take pointers to its arguments. I'm
guessing it binds them by const reference. This then trips UBSan. To
avoid this, we can copy the value into a temporary before passing to
EXPECT_EQ.
Second, the test to divide by 0 to trigger SIGFPE is undefined behavior.
The compiler is not actually obligated to trip SIGFPE. UBSan prints one
of its errors instead. Instead, since this file is only built on POSIX
anyway, use GCC inline assembly to do the division. That one is
well-defined.
Finally, casting a string to uint32_t* is undefined both by alignment
and by strict aliasing (although Chromium doesn't enable the latter).
Instead, type-punning should be done with memcpy.
Bug: chromium:1394755
Change-Id: I79108773a04ac26f5189e7b88a0acbf62eb4401d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4985905
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: David Benjamin <davidben@chromium.org>
Fixes a pending issue when we eventually move to C++20.
Original author: Dean Sturtevant
Change-Id: I7bb0648c73df6b6a28a3a4debdb4524d3cd27b38
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4979733
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Eric Astor <epastor@google.com>
Include check_op.h directly, instead of relying on the transitive
include from logging.h. This transitive include does not exist in
Chromium's //base.
Change-Id: I15962a9cdc26ac206032157b8d2659cf263ad695
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4950200
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
This CL rolls mini_chromium to pick up the move of a bunch of files
to base/apple, and makes changes to adjust.
Bug: chromium:1444927
Change-Id: Ib692e2a1628e2c0c8228795eaecdb7f35b1c09fa
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4786387
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Windows claims that heap corruption crashes are passed
to Windows Error Reporting but they are not, they are
swallowed and the process is simply terminated. WerFault.exe
does not run.
We can however intercept these crashes using a vectored
exception handler which forwards STATUS_HEAP_CORRUPTION
to the normal crash handler.
Adds an end-to-end test.
Bug: 2515
Change-Id: I2e1361dacef6fd03ea0f00327fee0b05a0c4899e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4637533
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Some versions of python call SetErrorMode which disables
WerFault handling for the fastfail test programs. We can
set this to a useful value, allowing these tests to run
again locally.
This does not enable the tests on the bots as they continue
to fail.
Bug: crashpad:458
Change-Id: Ibdd2f92ed872bd76490db32dccb2257dd91f8280
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4641231
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Lacros can be up to 2 milestones ahead of ash (and consequently the
platform code), so until the crash_reporter change has been in for 2
milestones, we need to manually check version compatibility.
BUG=chromium:1420445
TEST=Build, deploy, check that flag is set only on right version
Change-Id: Ic99d5ac58840814f7eeecd47c628ea0e8107f675
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4308129
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
In order to determine in crash_reporter whether a crash was fatal, we
need the exception number (-1 is not an actual crash).
BUG=b:269159625
TEST=deploy to DUT; chrome://crashdump; verify metadata present.
Change-Id: I83d3c9cc839a685af2f50d143d627cf9fcfaf3ac
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4265253
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Miriam Zimmerman <mutexlox@chromium.org>
from documentation of `ProcessException` in `crashpad_wer.h`:
```
//! \param[in] handled_exceptions is an array of exception codes that the helper
//! should pass on to crashpad handler (if possible). Pass nullptr and set
//! num_handled_exceptions to 0 to pass every exception on to the crashpad
//! handler.
```
fix the check to handle `num_handled_exceptions == 0` case to not filter
out any exceptions.
Bug: crashpad:439
Change-Id: Ic4559a730a26e37c7a8f13e6bcae7595d743924a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4206503
Commit-Queue: Alex Gough <ajgo@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
SDK definition of WER_RUNTIME_EXCEPTION_INFORMATION changed in SDK 19041
to add the bIsFatal field which we use. This adds a local definition of
the newer structure to allow the WER handler to build on earlier SDKs.
Bug: crashpad:423
Change-Id: I23bb69cc002ac8d469227e549f29b0af4849c893
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3880663
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Alex Gough <ajgo@chromium.org>
Empty arrays aren't allowed in C/C++, so we advise callers to pass
nullptr instead.
Change-Id: If6724fa5a8b657207337df8b36fa2b3b4fddd955
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3894498
Reviewed-by: Ben Hamilton <benhamilton@google.com>
Commit-Queue: Alan Zhao <ayzhao@google.com>
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>
registration_protocol_win.h includes <string>, which adds an
unacceptable dependency on libc++ in //components/crash/win:chrome_wer
in Chrome as that file is included in crashpad_wer.cc. Rather than
remove <string>, which would require doing a lot of transitive
refactoring work in Crashpad, we just extract the data structures into
another file, as crashpad_wer.cc only includes
registration_protocol_win.h for its struct definitions.
Bug: chromium:1357827
Change-Id: Ic20c2952be07ea75d063702cd346cdca0ab65038
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3864251
Commit-Queue: Alan Zhao <ayzhao@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When assertions were enabled in Chrome in https://crrev.com/c/3833545,
crashpad_wer now requires libc++ to be explicitly included if compiled
with -std=c++20 because <vector> would now reference symbols defined
outside the libc++ headers. We attempted to add libc++ as a dependency
in https://crrev.com/c/3862974; however, that was deemed unacceptable
because the library needs to be kept small in order for Windows to load
it to handle crashes. Therefore, the only alternative is to update the
library to remove std::vector
Bug: chromium:1357827
Change-Id: I1494204a7bd679fa1632a0f08597cb7e93267196
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3864248
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Alan Zhao <ayzhao@google.com>
Some documentation uses the old default branch name `master`.
But `master` in crashpad repo is a very old branch and has been
superseded with `main`.
Change-Id: I368c829fde2d29b3f14aa14185bfc97d546bf340
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3787194
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
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>
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>
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>
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>
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>
Stop the prune thread and the upload thread when moving to the
inactive/background state. This will reduce the number of 0xdead10cc
system kills from having a file lock during iOS suspend.
Wait to start the prune thread when the application is active.
Otherwise, for iOS prewarmed applications, the prune thread will
regularly start when the application is foregrounded for the first
time when the user intentionally runs the app.
It's still possible for either the prune thread or the upload thread to
have a file lock during iOS suspend, such as when a task started in the
foreground and does not complete in time for suspension. Future work
should include considering BackgroundTasks and/or NSURLSessions, which
can more safely run in the background.
Bug: crashpad: 400
Change-Id: Ic7d4687eb795fe585327f128aa84a5928141f4a9
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3517967
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
iOS applications may be terminated with the exception code 0xdead10cc
when holding on to file locks in the shared container during suspension.
One approach to minimize this is to request additional background
execution time to complete the locking operation (in this case the
CrashReportUpload thread and the PruneIntermediateDumpsAndCrashReports
thread).
Bug: crashpad:400
Change-Id: I4192ae1a92646ea337a09ac071e49761ab2d3860
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3517966
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Crashpad currently has a circular dependency: client->snapshot->client.
The dependency from snapshot -> client only exists to pull in a single
constant for Windows (CrashpadClient::kTriggeredExceptionCode), so this
change breaks the dependency by splitting the constant out into a new
file util/win/exception_codes.h.
Change-Id: I6b74b367df716e097758e63a44c53cb92ea5e04d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3450763
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Use BUILDFLAG(IS_*) instead of defined(OS_*).
This was generated mostly mechnically by performing the following steps:
- sed -i '' -E -e 's/defined\(OS_/BUILDFLAG(IS_/g' \
-e 's%([ !])OS_([A-Z]+)%\1BUILDFLAG(IS_\2)%g' \
$(git grep -l 'OS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- sed -i '' -e 's/#ifdef BUILDFLAG(/#if BUILDFLAG(/' \
$(git grep -l '#ifdef BUILDFLAG('
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- gsed -i -z -E -e \
's%(.*)#include "%\1#include "build/buildflag.h"\n#include "%' \
$(git grep -l 'BUILDFLAG(IS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- Spot checks to move #include "build/buildflag.h" to the correct parts
of files.
- sed -i '' -E -e \
's%^(#include "build/buildflag.h")$%#include "build/build_config.h"\n\1%' \
$(grep -L '^#include "build/build_config.h"$'
$(git grep -l 'BUILDFLAG(IS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'))
- Add “clang-format off” around tool usage messages.
- git cl format
- Update mini_chromium to 85ba51f98278 (intermediate step).
TESTING ONLY).
- for f in $(git grep -l '^#include "build/buildflag.h"$'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'); do \
grep -v '^#include "build/buildflag.h"$' "${f}" > /tmp/z; \
cp /tmp/z "${f}"; done
- git cl format
- Update mini_chromium to 735143774c5f (intermediate step).
- Update mini_chromium to f41420eb45fa (as checked in).
- Update mini_chromium to 6e2f204b4ae1 (as checked in).
For ease of review and inspection, each of these steps is uploaded as a
new patch set in a review series.
This includes an update of mini_chromium to 6e2f204b4ae1:
f41420eb45fa Use BUILDFLAG for OS checking
6e2f204b4ae1 Include what you use: string_util.h uses build_config.h
Bug: chromium:1234043
Change-Id: Ieef86186f094c64e59b853729737e36982f8cf69
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3400258
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Following https://crev.com/d3d85ce0b330b11f73f0495b7b99cea0d04d8c63,
the compiler now does not build an unwind library into the ASAN
runtime, nor is one available from the NDK in r23. Restoring Chrome's
standard dependencies (libcxx, libunwind) prevents a link error.
Bug: 1271628
Change-Id: I62d1c066bd7037276d78e2533dd5e4c3cf14f8c7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3298826
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Only the handler uses util/net. After
8342e6bd613a5b2e44eca1d74288e3115ccef139, the introduction of an
Objective-C class caused Chromium to emit duplicate class defintion
warnings in the component build.
Bug: chromium:1270609
Change-Id: I2770528347aef406bb21a79d295f702498f7b37e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3290276
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This implements a per-report retry rate limit (as opposed to per upload
rate limit in ShouldRateLimitUpload). When a report upload ends in a
retry state, an in-memory only timestamp is stored with the next
possible retry time. This timestamp is a backoff from the main thread
work interval, doubling on each attemt. Because this is only stored in
memory, on restart reports in the retry state will always be tried
once, and then fall back into the next backoff. This continues until
5 retry attempts are reached.
Change-Id: Ibde8855a8a9f0743f0b0bd4d5e3de8a45c64bcb6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3087723
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Manage the intermediate minidump generation, and own the crash report
upload thread and database.
Change-Id: I272d790a827cd13f6872e56f4675f366d13719c5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3087721
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This change was partially scripted and partially done manually with vim
regex + manually placing the deleted constructors.
The script change looked for destructors in the public: section of a
class, if that existed the deleted constructors would go before the
destructor.
For manual placement I looked for any constructor in the public: section
of the corresponding class. If there wasn't one, then it would ideally
have gone as the first entry except below enums, classes and typedefs.
This may not have been perfect, but is hopefully good enough. Fingers
crossed.
#include "base/macros.h" is removed from files that don't use
ignore_result, which is the only other thing defined in base/macros.h.
Bug: chromium:1010217
Change-Id: I099526255a40b1ac1264904b4ece2f3f503c9418
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3171034
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Standalone Crashpad for Android can now be built with gn.
Change-Id: I0ee7f8e1af8c2bc0edb88e93b345abd7d739f33c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3034984
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Remove unneeded base/strings/stringprintf.h includes.
ARCH_CPU_X86_64 macro is used without including build/build_config.h
Missing base/check.h
Change-Id: Ib7864ab7b30ef8fc37649783f7b90b618d0d6a0b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2920552
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
