* we start with VMOs in Fuchsia so this avoids a temporary file before writing the files in the database
* in order to do a soft transition, we add the new type and leave the old one until the caller in Fuchsia has been updated.
Bug: fuchsia:DX-1270
Change-Id: I3c77c775a186801dbcc7379e84ad5795f41780e7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1554011
Commit-Queue: Francois Rousseau <frousseau@google.com>
Reviewed-by: Scott Graham <scottmg@chromium.org>
now that we import fuchsia-sysinfo and fdio, this isn't really just zx anymore
Change-Id: Ic42359ce3d230e214ebdbbefb880ccb021434a0f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1555533
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
This reverts commit 5a21d038c9c9f3baa4e360b0a9bf5d6417868edf.
Reason for revert: Toolchain bug has now been fixed.
Original change's description:
> Work around libcrashpad_handler_trampoline.so ASan trunk clang problem
>
> This first landed downstream in Chromium at 7a8076717f11.
>
> Bug: chromium:936418
> Change-Id: I3eea804039829163948683f014bc10dee6477fb7
> Reviewed-on: https://chromium-review.googlesource.com/c/1495416
> Reviewed-by: Nico Weber <thakis@chromium.org>
> Commit-Queue: Mark Mentovai <mark@chromium.org>
TBR=thakis@chromium.org,mark@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:936418
Change-Id: I17d40865b64805ffdc1fb5e71e67fee1856c03b7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1546813
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
As of Android Q, the android_set_abort_message() function copies the
abort message into a mapping with a specific name that starts with a magic
number. This makes it possible for Crashpad to collect the abort message
by looking for the mapping with this name in procmaps and checking for the
magic number. The abort message is stored in a process annotation named
"abort_message".
Test: No regressions in build/run_tests.py on devices running P and Q
Test: Patched into Chromium; manually verified that HWASAN crash report appears in minidump
Bug: crashpad:287
Change-Id: I23c4d9e11015c84341de2d2e47e38a1eec508a36
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1544875
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This was broken by yours truly in
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1057833/,
probably because I couldn't decide whether to do it in HandleException()
or HandleExceptionHandles() (or possibly I'm just a dope).
In any case, suspending in HandleExceptionHandles() is fine, the thread
for the exception will be suspended on entry, so suspending other
threads after the initial excepting thread's koid to handle lookup is
OK.
This avoids a bunch of logspam like:
zx_thread_read_state(ZX_THREAD_STATE_GENERAL_REGS): ZX_ERR_BAD_STATE (-20)
and presumably will fix non-excepting-thread stacks being completely
broken?
Bug: fuchsia:DX-1190
Test: run `crasher write0_mt` on device
Change-Id: I029537aba2955d4f055471bf36a4e9a0f8ef2d5e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1536268
Reviewed-by: Francois Rousseau <frousseau@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This first landed downstream in Chromium at 7a8076717f11.
Bug: chromium:936418
Change-Id: I3eea804039829163948683f014bc10dee6477fb7
Reviewed-on: https://chromium-review.googlesource.com/c/1495416
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Starting with Android Q, Bionic's linker will support loading
executables from an APK, replacing the /system/bin/app_process
workaround.
libhandler_trampoline.so is a small executable, which `dlopen()`s
the handler code from another native library allowing
de-duplicating shared code with that library without having that
library available for a more direct link time dependency.
Bug: 928422
Change-Id: Ib126b8fca6005a34b9e4ef103eb1383dc0c554ea
Reviewed-on: https://chromium-review.googlesource.com/c/1477336
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
These flags are no longer tracked here since the macOS crashpad_handler
is built upstream as of https://crrev.com/629713
Bug: chromium:912286
Change-Id: I6735a6a1364086e67d1b7c2d316829c74c20d0d9
Reviewed-on: https://chromium-review.googlesource.com/c/1456777
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
These changes were made in the upstream version of crashpad without
being contributed back to crashpad.
Bug: crashpad:271
Change-Id: I60f6dfd206191e65bac41978a7c88d06b8c3cee9
Reviewed-on: https://chromium-review.googlesource.com/c/1389238
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is a follow-up to c8a016b99d97, following the post-landing
discussion at
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7
base::size, and std::size that will eventually replace it when C++17 is
assured, does not allow the size of non-static data members to be taken
in constant expression context. The remaining uses of ArraySize are in:
minidump/minidump_exception_writer.cc (×1)
minidump/minidump_system_info_writer.cc (×2, also uses base::size)
snapshot/cpu_context.cc (×4, also uses base::size)
util/misc/arraysize_test.cc (×10, of course)
The first of these occurs when initializing a constexpr variable. All
others are in expressions used with static_assert.
Includes:
Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao
f701716d9546 Add Windows ARM64 build target to mini_chromium
87a95a3d6ac2 Remove the arraysize macro
1f7255ead1f7 Placate MSVC in areas of base::size usage
737433ebade4 Add cast
Bug: chromium:837308
Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19
Reviewed-on: https://chromium-review.googlesource.com/c/1396108
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The sys/capability.h header is only present if libcap is installed. We
were only using it for its declaration of a capget() wrapper. Using the
system call directly allows compiling without installing libcap.
Change-Id: I83dfc5c8d56bb3cdd4efb62e0c568d8a221334cd
Reviewed-on: https://chromium-review.googlesource.com/c/1292231
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This configuration has the following dependencies layout:
* gtest should be pulled from //third_party/googletest
* zlib from //third_party/zlib
* base from //third_party/mini_chromium/mini_chromium/base
* Windows build configs come from //build/config/win:*.
Bug: crashpad:
Change-Id: I22b44d4f85349383063bf3785a321e3c23d88853
Reviewed-on: https://chromium-review.googlesource.com/c/1291378
Commit-Queue: Vyacheslav Egorov <vegorov@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
if only declared as deps, not public_deps, then any header file
depending on these headers need to also list these dependencies
Change-Id: I1d5f6a70d0fb80bf9d7368884247ceee036d1b14
Tested: CQ
Reviewed-on: https://chromium-review.googlesource.com/c/1282013
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
this allows us to upload that specific local report downstream
Bug: fuchsia:DX-543
Change-Id: Ide262575078aaf641f2e9321cd7796e9d1780f12
Tested: CQ
Reviewed-on: https://chromium-review.googlesource.com/c/1271998
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
zx_task_resume() is deprecated for exception resumption, and replaced by
zx_task_resume_from_exception(). The latter requires an additional
argument, so plumb the exception port on which the exception was
delivered through to where it needs to be resumed.
Bug: fuchsia:ZX-2720
Change-Id: If3984ce13eb1735d061faaac9eecd42e0251d25f
Reviewed-on: https://chromium-review.googlesource.com/c/1263017
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Francois Rousseau <frousseau@google.com>
Targets suffixed with "_module" are now treated specially in chromium
as dynamic feature modules.
Bug: crashpad:30
Change-Id: I9682a76a0e0fae993bbe7454c49a44ada6c4165b
Reviewed-on: https://chromium-review.googlesource.com/1150851
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
This function is just a renamed version of zx_get_startup_handle to
clarify the transfer of ownership.
Change-Id: Ic83cc592df3a571faebd788b3403ccfebd9ff3b8
Reviewed-on: https://chromium-review.googlesource.com/1099054
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: 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>
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 the beginning of support for attachments at the process level
being stored alongside a report. Attachments will be uploaded by key as
part of the multipart http upload. There's no interface at the client
level yet to pass these through.
As this is intended for Fuchsia, this is not yet implemented for the
Mac/Windows database implementations.
Bug: crashpad:196
Change-Id: Ieaf580675164b631d313193f97375710979ba2a9
Reviewed-on: https://chromium-review.googlesource.com/1060419
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The integration into the Fuchsia tree is still being negotiated, but
I've added crashsvc on that side
https://fuchsia.googlesource.com/zircon/+/HEAD/system/core/crashsvc/crashsvc.cpp,
which handles exceptions and spawns something to actually deal with the
crashed process. This means that there's no resident thing, so it seems
simplest to use handler/crash_report_exception_handler directly, rather
than add another wrapper binary. At some point it may make sense to roll
this functionality back into Crashpad upstream, we'll see how it
evolves.
Additionally, the "normal" crashpad_handler model may still be necessary
if Chrome wants to use a copy locally (rather than the system handler).
To accomplish this:
- Split crashpad_handler and crashpad_database_util packages so
crashpad_database_util can still be included into the system image for
debugging.
- Add handle-based version of HandleException() to
CrashReportExceptionHandler (and also remove the "type" argument because
I've come around to realizing there's no point to it, finally. :)
Bug: crashpad:196
Change-Id: I38872183ee3691c0938c5b761e6b73c80019f355
Reviewed-on: https://chromium-review.googlesource.com/1057833
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@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>
StartHandler() binds to the default job's exception port, and launches
the handler process (normally this is crashpad_handler), passing it the
task handle and a handle to the exception port as startup parameters.
This follows the protocol used by crashlogger.
Additionally, implement ExceptionHandlerServer in crashpad_handler,
which contains the exception processing loop. It currently dispatches to
an empty CrashReportExceptionHandler where a report will be written
eventually.
Bug: crashpad:196
Change-Id: Ie27ff6f67adfbcc7d03551ae7e84a885da43df5a
Reviewed-on: https://chromium-review.googlesource.com/1043282
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
There is not any normal way to package native executables in an
Android APK (that I've found). It is normal to package native code as
loadable modules, but Android's APK installer will ignore files not
named like shared objects.
Bug: crashpad:30
Change-Id: I45ea3e4b6dbfaf92d3d174e96aafe377928b9294
Reviewed-on: https://chromium-review.googlesource.com/1026157
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Building Crashpad with GCC flagged a few potential issues. The issues
don't seem particularly severe, but they are easy enough to fix.
Note that even with these changes, Crashpad will not cleanly build with
GCC (additional patches would be needed to third_party/mini_chromium).
Bug: crashpad:
Change-Id: I9289d6c918da9a111aa3c2a078ad0dc1ba84749f
Reviewed-on: https://chromium-review.googlesource.com/1014280
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Leonard Mosescu <mosescu@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>
Also fix an error in checking that PtraceClient was initialized.
Bug: crashpad:30
Change-Id: I1928340a2a642c2d831f0152bb9faaa12afb07e8
Reviewed-on: https://chromium-review.googlesource.com/978630
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>
end_to_end_test.py expects g_extra_memory_pointer data to be 32-bit,
so use a fixed-size type.
Change-Id: I5798bc8a895d7e02461671fd31e59dd178f6a6a4
Reviewed-on: https://chromium-review.googlesource.com/957792
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This caused an error with clang, but not msvc.
At first I thought this might be a discrepancy between the warning
levels used, but it appears msvc was okay with this because ints are
the same size as longs.
Change-Id: I798284fef9aa70b1bfda73308b9babe1779e8f4b
Reviewed-on: https://chromium-review.googlesource.com/941723
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
These flags were moved to mini_chromium's build/BUILD.gn, but that
configuration is not present when building in chromium.
Change-Id: I0d03c7461869882cf2ee7544ecd3d100eb189160
Reviewed-on: https://chromium-review.googlesource.com/940436
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Add the options:
--trace-parent-with-exception=<address>
which traces the handler's parent process which has an
ExceptionInformation struct at <address>.
--initial-client-fd=<fd>
which starts the handler server with an already connected client on
socket <fd>.
Bug: crashpad:30
Change-Id: Ied9760ca125a16f56173afdc56dff5fcb79d2eea
Reviewed-on: https://chromium-review.googlesource.com/922895
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
CrashpadClient will need ScopedPrSetPtracer when launching a handler
process in response to a crash.
Bug: crashpad:30
Change-Id: I35bc784b948349ca771f9cd65ef1089e626976bb
Reviewed-on: https://chromium-review.googlesource.com/927352
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
I can never remember which targets are buildable; this makes just
ninja -C out/lin
work, without too much fuss. I think this means we could turn on trybots
too, as I think all the tests that are built also run.
Bug: crashpad:30
Change-Id: I4759bb799dabf977c5b072691f28d00bf92bbebc
Reviewed-on: https://chromium-review.googlesource.com/924564
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Crash report upload is currently the responsibility of the embedding
client (e.g. Chrome) on Android.
Bug: crashpad:30
Change-Id: Ia658ec327783bd6d2ea6d7e279e942f458dd12ef
Reviewed-on: https://chromium-review.googlesource.com/922877
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This CL, based on
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/689745
adds a cross-platform database implementation side-by-side with the
existing macOS and Windows implementations. The generic implementation
is used for Linux, Android and Fuchsia.
The database uses the directory structure from the macOS
implementation, but stores report metadata in companion files for each
report, rather than using filesystem attributes. The database uses
lockfiles (companion files opened with O_EXCL) to protect report access
because they are widely supported across filesystems. Lost lockfiles
are removed after 3 days, along with any reports or metadata they were
protecting.
Bug: crashpad:206
Change-Id: I086e9001350e4446dd2f8c12fd3817377f509d3e
Reviewed-on: https://chromium-review.googlesource.com/919527
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This change adds CrashReportDatabase::UploadReport which owns the
report's file handle during upload. An upload is recorded as a success
by calling RecordUploadComplete(). If RecordUploadComplete() is not
called, the operation is recorded as a failure when the UploadReport is
destroyed.
Bug: crashpad:206
Change-Id: I8385d08d52185ad30b06a3ed054de9812ae006a2
Reviewed-on: https://chromium-review.googlesource.com/917983
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This change updates CrashReportDatbase::NewReport objects to own the
file handle associated with the new report, now accessible via a
FileWriter. NewReport's destructor closes its file handle and removes
its new report unless disarmed with FinishedWritingCrashReport,
eliminating the need for CallErrorWritingCrashReport.
Bug: crashpad:206
Change-Id: Iccb5bbc0ebadb07a237ff8eb938389afcfeae2a5
Reviewed-on: https://chromium-review.googlesource.com/916941
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@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>
- 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>
https://chromium-review.googlesource.com/c/chromium/mini_chromium/+/899847
turns the warning on. This adds one annotation, and fixes one bug.
Includes mini_chromium roll:
.../mini_chromium$ git log 5fcfa43c1587b94132e24782579350cb8266b990..3b953302848580cdf23b50402befc0ae09d03ff9 --oneline
3b95330 (HEAD, origin/master, origin/HEAD) Add -Wimplicit-fallthrough when building on clang
Bug: chromium:807632
Change-Id: I2f3ddca0228e52013844cb8d78d10cb359e851d0
Reviewed-on: https://chromium-review.googlesource.com/900317
Commit-Queue: Scott Graham <scottmg@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>
Messed up during rebase.
Bug: crashpad:79
Change-Id: I401c2112ec2810cb2fce792cf7b2a55643eeb4d8
Reviewed-on: https://chromium-review.googlesource.com/835530
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
In doing standalone bringup of Crashpad targeting Fuchsia, it seemed
tidy to keep the same literal paths to the dependencies that Chromium
needed and add stubs/forwarding to build/secondary in the Crashpad tree
as required to make those work.
However, when trying to build Crashpad in the Fuchsia tree itself, that
would require adding forwarding files to the Fuchsia tree to match the
Chromium directory structure, which would be awkward. Instead, have
explicit dependencies in the Crashpad tree that select the locations
for various dependencies.
Bug: crashpad:79, crashpad:196
Change-Id: Ib506839f9c97d8ef823663cdc733cbdcfa126139
Reviewed-on: https://chromium-review.googlesource.com/826025
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Adds a zlib build file for when building standalone (rather than reusing
Chromium's, though the code still Chromium's patched copy). The separate
build file avoids including the code for minizip and other support
targets (instead, only the main libzlib.a static_library is defined).
The other libraries and executables won't build in the Crashpad repo, so
having a local build file means that all targets defined in the GN build
are buildable.
generate_dump is passing an invalid handle to ProcessSnapshotFuchsia as
there's not yet any utility to convert a pid to a handle. But that's no
great loss, because ProcessSnapshotFuchsia doesn't do anything itself
yet.
Bug: crashpad:79, crashpad:196
Change-Id: I11c918a30b60cc071465c919315b45caab1de870
Reviewed-on: https://chromium-review.googlesource.com/809354
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Stubs a variety of classes (CrashReportExceptionHandler,
ExceptionHandlerServer, HTTPTransport, CrashReportDatabase).
Bug: crashpad:196
Change-Id: I4772f90d0d2ad07cc2f3c2ef119e92fde5c7acef
Reviewed-on: https://chromium-review.googlesource.com/809940
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
- Adds a .gn and a build/BUILDCONFIG.gn that uses mini_chromium's
build/BUILD.gn.
- Adds some stub BUILD.gn files in locations where Chromium expects them
(in //build, //testing, //third_party) containing empty targets/configs.
These are no-ops in standalone builds, but add functionality when
building in Chromium. This is in preference to having a global bool
that conditionally does Chromium-y things in the Crashpad build files.
These stub files are all contained in a secondary source root in
build/chromium_compatibility, referred to by //.gn.
- Adds //base/BUILD.gn which forwards to mini_chromium/base. This is
only used when building standalone so that both Chromium and Crashpad
can refer to it as "//base".
- Changes references to other Crashpad targets to be relatively
specified so that they work when the root of the project is //, and also
when it's //third_party/crashpad/crashpad as it is in Chromium.
- Moves any error-causing Mac/Win-specific files into explicit if (is_mac)
or if (is_win) blocks as part of removing the dependency on
set_sources_assignment_filter().
As yet unresolved:
- CRASHPAD_IN_CHROMIUM needs to be removed when standalone; to be tackled
in a follow up.
- Not sure what to do with zlib yet, the build file currently assumes
"in Chromium" too, and similarly having Crashpad //third_party/zlib:zlib
pointing at itself doesn't work.
Bug: crashpad:79
Change-Id: I6a7dda214e4b3b14a60c1ed285267ab97432a1a8
Reviewed-on: https://chromium-review.googlesource.com/777410
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Change-Id: I4b247d7fae1a212350f8ffcf2bf5ba1fa730f5c1
Reviewed-on: https://chromium-review.googlesource.com/780339
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Unreferenced, and not working at all in Crashpad-standalone.
Copied from Chromium at 52a9831d81f2099ef9f50fcdaca5853019262c35 to have
a point where a roll back into Chromium should be a no-op (with Chromium's
build/secondary/third_party/crashpad/... removed).
I'm not sure what we want to do about the various gni references into
Chromium (e.g. //build/config/sanitizers/sanitizers.gni, //testing/test.gni,
etc.) but I guess the sooner they live in Crashpad rather than in Chromium
the sooner we can figure out the sort of knobs and dials we need.
Bug: crashpad:79
Change-Id: Id99c29123bcd4174ee2bcc128c2be87e3c94fa3f
Reviewed-on: https://chromium-review.googlesource.com/777819
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This extracts string annotation objects from the minidumps and includes
them as form POST key-value pairs.
This change also starts building a crashpad_handler_test binary on Mac.
Bug: crashpad:192
Change-Id: I68cbf6fda6f1e57c1e621d5e3de8717cfaea65bf
Reviewed-on: https://chromium-review.googlesource.com/749793
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The design for running all Crashpad unit tests on Chromium’s try- and
buildbots involves pulling all tests into a single monolithic
crashpad_tests executable. Many Crashpad tests base the name of their
child executables or modules on the name of the main test executable.
Since the main test executable will have a different name in the
in-Chromium build, knowledge of the test executable name (referred to as
“module” here) needs to be added to the tests themselves.
This introduces TestPaths::BuildArtifact(), which allows the module name
to be specified. For Crashpad’s standalone build, the module name is
verified against the main test executable’s name.
TestPaths::BuildArtifact() can also locate paths in the alternate 32-bit
output directory for 64-bit Windows tests, taking on the responsibility
for what the new (5e9ed4cb9f69) TestPaths::Output32BitDirectory(), now
obsolete, did.
Bug: chromium:779790
Change-Id: I64c4a2190b6319e487c999812a7cfc512a75a700
Reviewed-on: https://chromium-review.googlesource.com/747536
Reviewed-by: Scott Graham <scottmg@chromium.org>
Crashpad’s own build always uses wWinMain(), the default entry point for
/subsystem:windows, producing crashpad_handler.exe. crashpad_handler.com
is a /subsystem:console version produced by running editbin on a copy of
crashpad_handler.exe. This leaves the entry point intact, so both copies
use wWinMain(). crashpad_handler.com does not use wmain() as
traditionally used by /subsystem:console programs.
For the in-Chromium build’s tests, it is conveient to produce the
/subsystem:console version, crashpad_handler.com, directly as linker
output, as opposed to using editbin to transform a /subsystem:windows
version. This /subsystem:console version uses the normal wmain() entry
point.
By providing both wWinMain() and wmain(), both build types can be
accommodated.
Bug: chromium:779790
Change-Id: Ieb784db0cc245c6e4c12fb1dd83b8b95e159bdec
Reviewed-on: https://chromium-review.googlesource.com/746161
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
As the crashing function runs inside GoogleTests SEH handler,
I think it, or something in the OS may be interfering with the
exception dispatch somehow. In any case, if this flakes, we have
no one to blame but ourselves.
Bug: crashpad:773569
Change-Id: I2230d02735be4a71b688e1acc94d0ae6f082d9bd
Reviewed-on: https://chromium-review.googlesource.com/739464
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
This is a step towards a database which gives out FileReaders in Report
objects instead of FilePaths.
Change-Id: I59704da65fc5521e5d47019416bf962c215d13bc
Reviewed-on: https://chromium-review.googlesource.com/721978
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Update mini_chromium to 7d6697ceb5cb5ca02fde3813496f48b9b1d76d0c
47ff9691450e Switch the language standard to C++14
7d6697ceb5cb Remove base/memory/ptr_util.h and base::WrapUnique
base::WrapUnique and std::make_unique are similar, but the latter is
standardized and preferred.
Most of the mechanical changes were made with this sed:
for f in $(git grep -l base::WrapUnique | uniq); do
sed -E \
-e 's%base::WrapUnique\(new ([^(]+)\((.*)\)\);%std::make_unique<\1>(\2);%g' \
-e 's%base::WrapUnique\(new ([^(]+)\);%std::make_unique<\1>();%g' \
-e 's%^#include "base/memory/ptr_util.h"$%#include <memory>%' \
-i '' "${f}"
done
Several uses of base::WrapUnique that did not fit on a single line and
were not matched by this sed were adjusted manually. All #include
changes were audited manually, to at least move <memory> into the
correct section. Where <memory> was already #included by a file (or its
corresponding header), the extra #include was removed. Where <memory>
should have been #included by a header, it was added. Other similar
adjustments to other #includes were also made.
Change-Id: Id4e0baad8b3652646bede4c3f30f41fcabfdbd4f
Reviewed-on: https://chromium-review.googlesource.com/714658
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
readdir_r() is a thread-safe version of readdir(), although readdir() is
not particularly thread-unsafe with most usage. The dirent* returned by
readdir() can only be invalidated by a subsequent readdir() or
closedir() on the same DIR*. In typical usage, where a returned dirent*
is used exclusively within a loop around readdir() and is not expected
to outlive that loop, there are no lifetime or thread-safety issues with
the use of readdir().
readdir_r() may be harmful in certain situations because its buffer is
not explicitly sized, and attempts to provide a suitably sized buffer
dynamically (which, incidentally, our code did not do) are subject to a
race condition.
https://elliotth.blogspot.com/2012/10/how-not-to-use-readdirr3.htmlhttps://womble.decadent.org.uk/readdir_r-advisory.html
glibc has already deprecated readdir_r(), and all Linux (including
Android) code was already using readdir(). This change eliminates
variant codepaths. It delegates buffer sizing (which we weren’t doing
correctly) to the C library, which also has more options at its disposal
to avoid races in sizing that buffer.
Change-Id: I4fca8948454116360180ad0017f226d06727ef81
Reviewed-on: https://chromium-review.googlesource.com/705756
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
hanging_program.exe is used by crash_other_program.exe, which is in turn
used by end_to_end_test.py. It hangs by loading loader_lock_dll.dll,
which squats in its entry point function while the loader lock is held.
hanging_program.exe needs to do some work in its Thread1() before the
loader lock is taken (a SetThreadPriority() call), and needs to do some
work in its main thread once the loader lock is held (it needs to signal
crash_other_program.exe that it’s successfully wedged itself).
Previously, proper synchronization was not provided. A 1-second Sleep()
was used to wait for the loader lock to be taken. Thread1() pre-work was
only achieved before the loader lock was taken by sheer luck. Things
didn’t always work out so nicely.
This uses an event handle to provide synchronization. An environment
variable is used to pass the handle to loader_lock_dll.dll, because
there aren’t many better options available. This eliminates both flake
and the unnecessary 1-second delay in hanging_program.exe, and since
this program runs twice during end_to_end_test.py, it improves that
test’s runtime by 2 seconds.
Bug: crashpad:197
Test: end_to_end_test.py
Change-Id: Ib9883215ef96bed7571464cc68e09b6ab6310ae6
Reviewed-on: https://chromium-review.googlesource.com/700076
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
During crash report upload, the client now provides the product
name, version, and client id via URL parameters to the crash
reporting service.
Also added percent-encoding function and a test.
Change-Id: I62f3a646d4ab6029543bd80938b79de28b1f20e4
Test: crashpad_util_test URLEncode.Empty
Test: crashpad_util_test URLEncode.ReservedCharacters
Test: crashpad_util_test URLEncode.UnreservedCharacters
Test: crashpad_util_test URLEncode.SimpleAddress
Reviewed-on: https://chromium-review.googlesource.com/493917
Commit-Queue: Roman Margold <rmargold@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is essentially based on a search for “^ *const [^*&]*=[^(]*$”
Change-Id: Id571119d0b9a64c6f387eccd51cea7c9eb530e13
Reviewed-on: https://chromium-review.googlesource.com/585555
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
The "file-limit" annotation has shown that the system as a whole is not
likely to be out of file descriptors globally. It’s possible that a file
descriptor leak in crashpad_handler itself is responsible for certain
crashes. Add a count of the number of open files in the handler process
to this annotation to test this theory.
Bug: crashpad:180
Change-Id: If6f2304fdabddd29636ba4ac5a7d1e0fff7f4b61
Reviewed-on: https://chromium-review.googlesource.com/585852
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This uses “static” at function scope to avoid making local copies, even
in cases where the compiler can’t see that the local copy is
unnecessary. “constexpr” adds additional safety in that it prevents
global state from being initialized from any runtime dependencies, which
would be undesirable.
At namespace scope, “constexpr” is also used where appropriate.
For the most part, this was a mechanical transformation for things
matching '(^| )const [^=]*\['.
Similar transformations could be applied to non-arrays in some cases,
but there’s limited practical impact in most non-array cases relative to
arrays, there are far more use sites, and much more manual intervention
would be required.
Change-Id: I3513b739ee8b0be026f8285475cddc5f9cc81152
Reviewed-on: https://chromium-review.googlesource.com/583997
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
The "file-limit" annotation will be used to confirm the theory that
certain crashes are caused by systems at or near their file descriptor
table size limits.
The annotation records the system-wide kern.num_files and kern.maxfiles
values, and the process-specific current and maximum file descriptor
limits.
The annotation will be set on crashpad_handler startup, and will be
refreshed every time an exception is handled and every time the upload
thread processes a pending report.
It’s expected that this annotation will be removed after enough data has
been collected to confirm the theory. However, the principle is useful
enough that we may want to provide this feature more generally under
bugs 19 or 21.
Bug: crashpad:180
Change-Id: I3bb78fae60e0567bc4ac2625716e0abe0ddae08c
Reviewed-on: https://chromium-review.googlesource.com/479914
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Self-monitoring revealed this CHECK was being hit in the wild:
base::debug::BreakDebugger() debugger_posix.cc:260
logging::LogMessage::~LogMessage() logging.cc:759
logging::MachLogMessage::~MachLogMessage() mach_logging.cc:45
crashpad::ExceptionHandlerServer::Run() exception_handler_server.cc:108
crashpad::HandlerMain() handler_main.cc:744
The MACH_CHECK() was:
108 MACH_CHECK(mr == MACH_MSG_SUCCESS, mr) << "MachMessageServer::Run";
Crash reports captured the full message, including the value of mr:
[0418/015158.777231:FATAL:exception_handler_server.cc(108)] Check failed: mr == MACH_MSG_SUCCESS. MachMessageServer::Run: (ipc/send) invalid destination port (0x10000003)
0x10000003 = MACH_SEND_INVALID_DEST.
This can happen when attempting to send a Mach message to a dead name.
Send (and send-once) rights become dead names when the corresponding
receive right dies. This would not normally happen for exception
requests originating in the kernel. It can happen for requests
originating from a user task: when the user task dies, the receive right
dies with it. All it takes to trigger this CHECK() in crashpad_handler
is for a Crashpad client to die (or be killed) while the handler is
processing a SimulateCrash() that the client originated.
Accept MACH_SEND_INVALID_DEST as a valid return value for
MachMessageServer::Run().
Note that MachMessageServer’s test coverage was already aware of this
behavior. MachMessageServer::Run()’s documentation is updated to reflect
it too.
Change-Id: I483c065d3c5f9a7da410ef3ad54db45ee53aa3c2
Reviewed-on: https://chromium-review.googlesource.com/479093
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
76a67a37b1d0 adds crashpad_handler’s --monitor-self argument, which
results in a second crashpad_handler instance running out of the same
database as the initial crashpad_handler instance that it monitors. The
two handlers start at nearly the same time, and will initially be on
precisely the same schedule for periodic tasks such as scanning for new
reports to upload and pruning the database. This is an unnecessary
duplication of effort.
This adds a new --no-periodic-tasks argument to crashpad_handler. When
the first instance of crashpad_handler starts a second to monitor it, it
will use this argument, which prevents the second instance from
performing these tasks.
When --no-periodic-tasks is in effect, crashpad_handler will still be
able to upload crash reports that it knows about by virtue of having
written them itself, but it will not scan the database for other pending
reports to upload.
Bug: crashpad:143
Test: crashpad_util_test ThreadSafeVector.ThreadSafeVector
Change-Id: I7b249dd7b6d5782448d8071855818f986b98ab5a
Reviewed-on: https://chromium-review.googlesource.com/473827
Reviewed-by: Robert Sesek <rsesek@chromium.org>
With multiple crashpad_handlers running out of the same database, it was
possible for more than one to attempt to upload the same report. Nothing
ensured that the reports remained pending between the calls to
CrashReportDatabaseMac::GetPendingReports() and
CrashReportDatabaseMac::GetReportForUploading().
The Windows equivalent did not share this bug, but it would return
kBusyError. kReportNotFound is a better code.
Test: crashpad_client_test CrashReportDatabaseTest.*
Change-Id: Ieaee7f94ca8e6f2606d000bd2ba508d3cfa2fe07
Reviewed-on: https://chromium-review.googlesource.com/473928
Reviewed-by: Robert Sesek <rsesek@chromium.org>
--monitor-self-annotations allows the Crashpad-using application to push
module-level annotations in to crashpad_handler. These annotations will
appear in any crash report written for that handler by --monitor-self.
Bug: crashpad:143
Change-Id: If47395da75a90be4f4bdce0630ce95ea93f9fcf3
Reviewed-on: https://chromium-review.googlesource.com/467746
Reviewed-by: Scott Graham <scottmg@chromium.org>
https://crbug.com/678959 added “fallback” crash reporting for
crashpad_handler on Windows, in a Chrome- and Windows-specific way. This
implements a more general self-monitor mechanism that will work on
multiple platforms and in the absence of Chrome.
When starting crashpad_handler (let’s call it the “first instance”) with
--monitor-self, it will start another crashpad_handler (the “second
instance”). The second instance monitors the first one for crashes. The
second instance will be started in mostly the same way as the first
instance, except --monitor-self will not be provided to the second
instance.
Bug: crashpad:143
Change-Id: I76f3f47d1762d8ecae1814357cb672c8b7bd5e95
Reviewed-on: https://chromium-review.googlesource.com/466267
Reviewed-by: Sigurður Ásgeirsson <siggi@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This supports the “double handler” or “double handler with low
probability” models from https://crashpad.chromium.org/bug/143.
For crashpad_handler to be become its own client, it needs access to its
own executable path to pass to CrashpadClient::StartHandler(). This was
formerly available in the test-only test::Paths::Executable(). Bring
that function’s implementation to the non-test Paths::Executable() in
util/misc, and rename test::Paths to test::TestPaths to avoid future
confusion.
test::TestPaths must still be used to access TestDataRoot(), which does
not make any sense to non-test code.
test::TestPaths::Executable() is retained for use by tests, which most
likely prefer the fatal semantics of that function. Paths::Executable()
is not fatal because for the purposes of implementing the double
handler, a failure to locate the executable path (which may happen on
some systems in deeply-nested directory hierarchies) shouldn’t cause the
initial crashpad_handler to abort, even if it does prevent a second
crashpad_handler from being started.
Bug: crashpad:143
Test: crashpad_util_test Paths.*, crashpad_test_test TestPaths.*
Change-Id: I9f75bf61839ce51e33c9f7c0d7031cebead6a156
Reviewed-on: https://chromium-review.googlesource.com/466346
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This is like 270490ff79df, but for things run by end_to_end_test.py, and
things run for it by crash_other_program.exe.
Change-Id: Iabf3c762c50f41eb61ab31f714c646364196e745
Reviewed-on: https://chromium-review.googlesource.com/458822
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
ReadFile() attempted to continue reading after a short read. In most
cases, this is fine. However, ReadFile() would keep trying to fill a
partially-filled buffer until experiencing a 0-length read(), signaling
end-of-file. For certain weird file descriptors like terminal input, EOF
is an ephemeral condition, and attempting to read beyond EOF doesn’t
actually return 0 (EOF) provided that they remain open, it will block
waiting for more input. Consequently, ReadFile() and anything based on
ReadFile() had an undocumented and quirky interface, which was that any
short read that it returned (not an underlying short read) actually
indicated EOF.
This facet of ReadFile() was unexpected, so it’s being removed. The new
behavior is that ReadFile() will return an underlying short read. The
behavior of FileReaderInterface::Read() is updated in accordance with
this change.
Upon experiencing a short read, the caller can determine the best
action. Most callers were already prepared for this behavior. Outside of
util/file, only crashpad_database_util properly implemented EOF
detection according to previous semantics, and adapting it to new
semantics is trivial.
Callers who require an exact-length read can use the new
ReadFileExactly(), or the newly renamed LoggingReadFileExactly() or
CheckedReadFileExactly(). These functions will retry following a short
read. The renamed functions were previously called LoggingReadFile() and
CheckedReadFile(), but those names implied that they were simply
wrapping ReadFile(), which is not the case. They wrapped ReadFile() and
further, insisted on a full read. Since ReadFile()’s semantics are now
changing but these functions’ are not, they’re now even more distinct
from ReadFile(), and must be renamed to avoid confusion.
Test: *
Change-Id: I06b77e0d6ad8719bd2eb67dab93a8740542dd908
Reviewed-on: https://chromium-review.googlesource.com/456676
Reviewed-by: Robert Sesek <rsesek@chromium.org>
BUG=crashpad:165, chromium:696721
Change-Id: I85c6740955fdbdfd7f17208c095a4685e28bfacc
Reviewed-on: https://chromium-review.googlesource.com/448960
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Use these utilities for signal handling in crashpad_handler
BUG=crashpad:30
TEST=crashpad_util_test Signals.*
Change-Id: I6c9a1de35c4a81b58d77768c4753bdba5ebea4df
Reviewed-on: https://chromium-review.googlesource.com/446917
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Chromium has many build configurations. One important configuration
that’s not tested by its commit queue doesn’t use |condition| in
DLOG_IF(severity, condition) or any of the D*LOG_IF macros, resulting in
errors such as
…/handler/handler_main.cc:166:7: error: unused variable 'rv' [-Werror,-Wunused-variable]
int rv = sigaction(sig, &sa, nullptr);
^
BUG=chromium:695314
Change-Id: I09a57379e8276b5ffa7f8f81706581a802d76809
Reviewed-on: https://chromium-review.googlesource.com/446559
Reviewed-by: Robert Sesek <rsesek@chromium.org>
It could be useful to put our existing Crashpad.HandlerCrashed metrics
into context by getting a sense of handler starts, clean exits, and
other types of exits.
BUG=crashpad:100
Change-Id: I8982075158ea6d210eb2ddad678302e339a42192
Reviewed-on: https://chromium-review.googlesource.com/444124
Reviewed-by: Scott Graham <scottmg@chromium.org>
This adds zlib to Crashpad. By default in standalone Crashpad builds,
the system zlib will be used where available. A copy of Chromium’s zlib
(currently a slightly patched 1.2.11) is checked out via DEPS into
third_party for use on Windows, which does not have a system zlib.
zlib is used to produce gzip streams for HTTP upload request bodies sent
by crashpad_handler by default. The Content-Encoding: gzip header is set
for these compressed request bodies. Compression can be disabled for
upload to servers without corresponding decompression support by
starting crashpad_handler with the --no-upload-gzip option.
Most minidumps compress quite well with zlib. A size reduction of 90% is
not uncommon.
BUG=crashpad:157
TEST=crashpad_util_test GzipHTTPBodyStream.*:HTTPTransport.*
Change-Id: I99b86db3952c3685cd78f5dc858a60b54399c513
Reviewed-on: https://chromium-review.googlesource.com/438585
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This installs signal handlers in the crashpad_handler process to log
these crashes via the Crashpad.HandlerCrash.ExceptionCode.Mac histogram.
This is roughly the same mechanism that’s used for Windows.
The signal handler tries fairly hard to avoid swallowing signals, so
that things appear to outside observers (including debuggers and crash
handlers) identically to how they would look if no signal handler was
present.
The signal handler uses a different mapping schema than the existing
Crashpad.ExceptionCode.Mac histogram for reasons explained in code
comments. Because the mappings should not overlap, the new values may be
added to the existing CrashpadMacExceptionCodes enum.
BUG=crashpad:100
Change-Id: I9b8bda1c59d0a180501c285cdc672840a54f5efc
Reviewed-on: https://chromium-review.googlesource.com/435451
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Previously, only the top-level exception code was reported via the
Crashpad.ExceptionCode.Mac histogram. Making this histogram work
(https://crbug.com/678720) has revealed that Chrome is triggering
EXC_RESOURCE exceptions at a rate in excess of 4x that of ordinary
crashes. These exceptions were not previously visible because they are
not uploaded unless the system treats them as fatal, which it does not
normally do absent an explicit request.
In order to learn more about the problem, this change augments the data
reported via the Crashpad.ExceptionCode.Mac histogram to report (at
least) second-level exception data. This means that we will no longer
see just EXC_RESOURCE, but potentially more useful information such as
EXC_RESOURCE / RESOURCE_TYPE_IO / FLAVOR_IO_PHYSICAL_WRITES. This also
applies to other exception types, so that the majority of crashes
currently falling into the EXC_CRASH bucket will now have additional
information decoded and will be reported as, for example, EXC_BAD_ACCESS
/ KERN_INVALID_ADDRESS, EXC_BAD_INSTRUCTION / EXC_I386_INVOP, and
EXC_CRASH / SIGABRT.
Because the old mechanism was only live (in an “it works” sense) for
several days, and the new mechanism does not overlap with histogram
values used by the old one, there’s no need to invent a new histogram
name.
BUG=chromium:684051
Change-Id: Ia0a372b4127f7b3b2e7dbbaac9304cce3b5aadfe
Reviewed-on: https://chromium-review.googlesource.com/430933
Reviewed-by: Scott Graham <scottmg@chromium.org>
I haven't been able to reproduce this locally, but we see errors in
crash dumps where the unloaded module list consists of a number of
modules with invalid names and implausible addresses. My assumption is
that RTL_UNLOAD_EVENT_TRACE isn't correct for some OS levels. Instead of
trying to finesse and test that, use RtlGetUnloadEventTraceEx() instead
of RtlGetUnloadEventTrace(), which returns an element size. (This
function is Vista+ which is why it wasn't used the first time around.)
R=mark@chromium.org
BUG=chromium:620175
Change-Id: I4d7080a03623276f9c1c038d6e7329af70e4a64c
Reviewed-on: https://chromium-review.googlesource.com/421564
Reviewed-by: Mark Mentovai <mark@chromium.org>
The strangest discovery relates to the # <h1> title in navbar.md.
Gitiles renders it small unless there’s a [home] reference, so use that.
This should only affect wrapping the site logo in the [home] link, but
it appears to control the size of the navbar title too. See
https://code.google.com/p/gitiles/issues/detail?id=130.
BUG=crashpad:138,gitiles:130
Change-Id: I11b3a79f045efa22358b3c3ef4b50ce2e6b3282e
Reviewed-on: https://chromium-review.googlesource.com/408458
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Most of the world, including the Chromium universe, seems to be
standardizing on Markdown for documentation. Markdown provides the
benefit of automatic rendering on Gitiles (Gerrit), and on GitHub
mirrors as well. Crashpad should fit in with its surroundings.
There are two quirks that I was unable to resolve.
- Markdown does not allow **emphasis** within a ```code fence```
region. In blocks showing interactive examples, the AsciiDoc
documentation used this to highlight what the user was expected to
type.
- Markdown does not have a “definition list” (<dl>). This would have
been nice in man pages for the Options and Exit Status sections.
In its place, I used unnumbered lists. This is a little ugly, but
it’s not the end of the world.
The new Markdown-formatted documentation is largely identical to the
AsciiDoc that it replaces. Minor editorial revisions were made.
References to Mac OS X now mention macOS, and tool man pages describing
tools that that access task ports now mention System Integrity
Protection (SIP).
The AppEngine-based https://crashpad.chromium.org/ app in doc/appengine
is still necessary to serve Doxygen-generated documentation. This app is
updated to redirect existing generated-HTML URLs to Gitiles’ automatic
Markdown rendering.
Scripts in doc/support are updated to adapt to this change. All AsciiDoc
support files in doc/support have been removed.
BUG=crashpad:138
Change-Id: I15ad423d5b7aa1b7aa2ed1d2cb72639eec7c81aa
Reviewed-on: https://chromium-review.googlesource.com/408256
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
The Windows 10 loader starts a few extra threads before main(). In a few
of the test cases, the tests were relying on thread ordering (generally,
the test thread being at index #1). Instead, use other signals to find
the correct thread to verify.
R=mark@chromium.org
Change-Id: Icb1f5a8fdf3a0ea6d82ab65960dbcb650965f269
Reviewed-on: https://chromium-review.googlesource.com/407073
Reviewed-by: Mark Mentovai <mark@chromium.org>
Not surprisingly,
"0x278,0x27c,0x280,0x274,0x288,0x978a70,0x978a80,0x978a90" is not a
valid directory to store metrics in.
Fortunately --metrics was processed before --initial-client-data in a
local build, otherwise this could have lurked for a long time. :(
R=mark@chromium.org
BUG=655788,656800
Change-Id: I3ac3d1b487f55ddf0172bac51f8d9efc411c3329
Reviewed-on: https://chromium-review.googlesource.com/406938
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, StartHandler() launched the handler process, then connected
over a pipe to register for crash handling. Instead, the initial client
can create and inherit handles to the handler and pass those handle
values and other data (addresses, etc.) on the command line.
This should improve startup time as there's no need to synchronize with
the process at startup, and allows avoiding a call to CreateProcess()
directly in StartHandler(), which is important for registration for
crash reporting from DllMain().
Incidentally adds new utility functions for string/number conversion and
string splitting.
Note: API change; UseHandler() is removed for all platforms.
BUG=chromium:567850,chromium:656800
Change-Id: I1602724183cb107f805f109674c53e95841b24fd
Reviewed-on: https://chromium-review.googlesource.com/400015
Reviewed-by: Mark Mentovai <mark@chromium.org>
Three new metrics:
- counting upload success/failure;
- enum tracking the reason upload was skipped;
- enum describing how an upload got to the pending state.
R=mark@chromium.org, asvitkine@chromium.org
BUG=crashpad:100
Change-Id: I5e0cbc1ac3424e974f3a51560e5cdad484ffc038
Reviewed-on: https://chromium-review.googlesource.com/388855
Reviewed-by: Mark Mentovai <mark@chromium.org>
Includes mini_chromium DEPS roll for:
88e0a3e Add stub of sparse_histogram.h
R=mark@chromium.org
BUG=crashpad:100
Change-Id: I4c541a33be0f7f47e972af638d4765bd06682acf
Reviewed-on: https://chromium-review.googlesource.com/386385
Reviewed-by: Mark Mentovai <mark@chromium.org>
In order to allow on-demand uploads for crash reports, adding a
upload_explicitly_requested bit on 'pending' state and necessary support
for it.
BUG=chromium:620762
Change-Id: Ida38e483fe8d0e48eb5cbe95e8b8bfd96a2f8f00
Reviewed-on: https://chromium-review.googlesource.com/367328
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This switches the default behaviour of crashpad_handler.exe to be a
/subsystem:windows app, so that normal usage won't cause a console to be
popped up. At the same time, creates a copy of crashpad_handler.exe in
the output dir named crashpad_handler.com. The .com doesn't affect
normal operation, as the way StartHandler() uses CreateProcess()
requires a real path to a file. However, when run from a command prompt,
.com are found before .exe, so editbin the .com to be to a console app,
which will be run in preference to the exe when run as just
"crashpad_handler", as one tends to do from a command prompt when
debugging. That is:
d:\src\crashpad\crashpad\out\Debug>where crashpad_handler
d:\src\crashpad\crashpad\out\Debug\crashpad_handler.com
d:\src\crashpad\crashpad\out\Debug\crashpad_handler.exe
d:\src\crashpad\crashpad\out\Debug>crashpad_handler --help
Usage: crashpad_handler [OPTION]...
...
d:\src\crashpad\crashpad\out\Debug>crashpad_handler.exe --help
<no output>
d:\src\crashpad\crashpad\out\Debug>crashpad_handler.com --help
Usage: crashpad_handler.com [OPTION]...
...
We also use the .com file in test invocations so that output streams
will be visible.
R=mark@chromium.org
Change-Id: I1a27f88472d491b2a1d76e63c45e6415d9f679c0
Reviewed-on: https://chromium-review.googlesource.com/371578
Reviewed-by: Mark Mentovai <mark@chromium.org>
Because DumpAndCrashTargetProcess() suspends the process, the thread
suspend count is one too high for all threads other than the injection
one in the thread snapshots. Compensate for this when we detect this
type of exception.
BUG=crashpad:103
Change-Id: Ib77112fddf5324fc0e43f598604e56f77d67ff54
Reviewed-on: https://chromium-review.googlesource.com/340372
Reviewed-by: Mark Mentovai <mark@chromium.org>
Adds a new client API which allows causing an exception in another
process. This is accomplished by injecting a thread that calls
RaiseException(). A special exception code is used that indicates to the
handler that the exception arguments contain a thread id and exception
code, which are in turn used to fabricate an exception record. This is
so that the API can allow the client to "blame" a particular thread in
the target process.
The target process must also be a registered Crashpad client, as the
normal exception mechanism is used to handle the exception.
The injection of a thread is used instead of DebugBreakProcess() which
does not cause the UnhandledExceptionFilter() to be executed.
NtCreateThreadEx() is used in lieu of CreateRemoteThread() as it allows
passing of a flag which avoids calling DllMain()s. This is necessary to
allow thread creation to succeed even when the target process is
deadlocked on the loader lock.
BUG=crashpad:103
Change-Id: I797007bd2b1e3416afe3f37a6566c0cdb259b106
Reviewed-on: https://chromium-review.googlesource.com/339263
Reviewed-by: Mark Mentovai <mark@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>
This augments the standalone and in-Chromium models with an external
model, in which the dependencies and Crashpad are checked out as
siblings in the same directory, organized according to this structure:
root/crashpad[/README]
root/gmock[/include/gmock/gmock.h]
root/gtest[/include/gtest/gtest.h]
root/gyp[/pylib/gyp]
root/mini_chromium[/build/common.gypi]
This is the directory structure used in google3.
Change-Id: Ie300ead7cd085265933e4ed891509ce050e995e2
Reviewed-on: https://chromium-review.googlesource.com/324230
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
The previous approach was nice for its simplicity, but unfortunately
didn't work when the compiler decided to do some of its confounded
"optimization".
R=mark@chromium.org
BUG=crashpad:86, chromium:571144
Review URL: https://codereview.chromium.org/1563273004 .
This is a temporary measure to try to account for lower than expected
upload volume from Chrome in the wild. So this doesn't fix bug 23, but
is related. The ability to delimit the upload rate is useful when
testing locally too.
R=mark@chromium.org
BUG=crashpad:23
Review URL: https://codereview.chromium.org/1563683002 .
This was done in Chromium’s local copy of Crashpad in 562827afb599. This
change is similar to that one, except more care was taken to avoid
including headers from a .cc or _test.cc when already included by the
associated .h. Rather than using <stddef.h> for size_t, Crashpad has
always used <sys/types.h>, so that’s used here as well.
This updates mini_chromium to 8a2363f486e3a0dc562a68884832d06d28d38dcc,
which removes base/basictypes.h.
e128dcf10122 Remove base/move.h; use std::move() instead of Pass()
8a2363f486e3 Move basictypes.h to macros.h
R=avi@chromium.org
Review URL: https://codereview.chromium.org/1566713002 .
../../handler/crash_report_upload_thread.cc:142:7: error: field 'database_' will be initialized after field 'thread_' [-Werror,-Wreorder]
database_(database),
^
1 error generated.
And:
..\util\thread\worker_thread_test.cc(25) : warning C4244: 'initializing' : conversion from 'double' to 'const uint64_t', possible loss of data
BUG=crashpad:22
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1556043005 .
This more-natural spelling doesn’t require Crashpad developers to have
to remember anything special when writing code in Crashpad. It’s easier
to grep for and it’s easier to remove the “compat” part when pre-C++11
libraries are no longer relevant.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1513573005 .
Previously, there was a window after starting the upload thread but
before the SIGTERM handler was installed, where receipt of SIGTERM
could have interrupted an in-progress upload. There was also the
possibility that a second SIGTERM sent after the exception handler
stopped running would interrupt an in-progress upload. By pulling the
signal handler out of ExceptionHandlerServer and into the main
function, these races are avoided.
BUG=crashpad:25
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1429353002 .
