I’m most interested in picking up 1b3eb6ef3462, “Explicitly define copy
constructors used in googletest tests.”
This also reorganizes files and rewrites text to refer to this project
as Google Test and googletest (and Google Mock and googlemock), as it
prefers to be known. Some filenames are left at gtest_* following the
precedent set by gtest itself. For example, #include "gtest/gtest.h" is
still used, so #include "test/gtest_death.h" is retained too.
gtest_all_test OutputFileHelpersTest.GetCurrentExecutableName hard-codes
the expected executable name as gtest_all_test among other options that
do not include googletest_all_test, so test executables retain their
names as well.
fb19f57880f6 Add GTEST_BRIEF option
3549237957a1 Ensure that gtest/gmock pkgconfig requirements specify
version
189299e957bb Merge branch 'master' into quiet-flag
5504ded3ab5c Fix a typo in .travis.yml
6ed4e7168f54 Replace the last instance of `throw()` with `noexcept`. NFC
879fd9b45299 Remove duplicate codes existed in get-nprocessors.sh
644f3a992c28 gtest-unittest-api_test - fix warning in clang build
0b6d567619fe Remove redundant .c_str()
be3ac45cf673 fix signed/unsigned comparison issue (on OpenBSD)
b51a49e0cb82 Merge pull request #2773 from Quuxplusone:replace-noexcept
c2032090f373 Merge pull request #2772 from Quuxplusone:travis
4fe5ac53337e Merge pull request #2756 from Conan-Kudo:fix-pkgconfig-reqs
373d72b6986f Googletest export
4c8e6a9fe1c8 Merge pull request #2810 from ptahmose:master
71d5df6c6b67 Merge pull request #2802 from e-i-n-s:fix_clang_warning
dcc92d0ab6c4 Merge pull request #2805 from pepsiman:patch-1
4f002f1e236c VariadicMatcher needs a non-defaulted move constructor for
compile-time performance
9d580ea80592 Enable protobuf printing for open-source proto messages
766ac2e1a413 Remove all uses of GTEST_DISALLOW_{MOVE_,}ASSIGN_
11b3cec177b1 Fix a -Wdeprecated warning
01c0ff5e2373 Fix a -Wdeprecated warning
c7d8ec72cc4b Fix a -Wdeprecated warning
1b066f4edfd5 Add -Wdeprecated to the build configuration
4bab55dc54b4 Removed a typo in README.md
a67701056425 Googletest export
fb5d9b66c5b0 Googletest export
1b3eb6ef3462 Googletest export
b0e53e2d64db Merge pull request #2797 from Jyun-Neng:master
d7ca9af0049e Googletest export
955552518b4e Googletest export
ef25d27d4604 Merge pull request #2815 from Quuxplusone:simple
129329787429 Googletest export
b99b421d8d68 Merge pull request #2818 from inazarenko:master
472cd8fd8b1c Merge pull request #2818 from inazarenko:master
3cfb4117f7e5 Googletest export
0eea2e9fc634 Googletest export
a9f6c1ed1401 Googletest export
1a9c3e441407 Merge pull request #2830 from keshavgbpecdelhi:patch-1
e589a3371705 Merge pull request #2751 from calumr:quiet-flag
Change-Id: Id788a27aa884ef68a21bae6c178cd456f5f6f2b0
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2186009
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Add Mach exception server and fill out exceptions snapshot.
Note that:
- The 'capture' portion of this CL will be moved out of the snapshot
interface and into a separate in-process dump to disk location.
- All of the pointer dereferences need to be wrapped in vm_read.
- The read-fast-and-dump logic in exception_snapshot will end up in a
different file completely, but until we pick a
serialization/deserialization method, keep it as-is.
Bug: crashpad:31
Change-Id: I44203aa44036a341d6b4517fde7ab0cb9d7e94d7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2160122
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
* Fuchsia only uses Crashpad for minidump generation, report database
and report upload, not for the actual exception handling so it does
not need a handler class
* the current handler class didn't have tests anyway
* Chromium on Fuchsia relies on the platform exception handling instead
of rolling its own Crashpad exception handler
* this avoids us having to maintain an exception handler in another repo
* this removes the last FIDL dependency in Crashpad
TESTED=`fx test crashpad_test`
Change-Id: Ie3998f709e7cc4252dd551882a23b337864da85e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2165638
Commit-Queue: Francois Rousseau <frousseau@google.com>
Reviewed-by: Scott Graham <scottmg@chromium.org>
mach_extensions is sensible on iOS, but bootstrap is not available
outside of macOS. To allow mach_extensions to be used cleanly on iOS,
the bootstrap code is moved into its own macOS-specific file.
Bug: crashpad:31
Change-Id: I7bf9d5194253b563954a1e55fbf67a16f686e8ff
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2154529
Reviewed-by: Justin Cohen <justincohen@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
- Fix -Wundeclared-selector in Chromium roll.
- Convert TEST to TEST_F in crashpad_client_ios_test.mm
Also rolls mini_chromim 731e08f06..641fcf9bb (3 commits)
2020-04-14 mark Mark static const class/struct members as constexpr
2020-04-09 justincohen Add PlatformTest to mini_chromium.
2020-04-09 jperaza Replace ScopedClearErrno with ScopedClearLastError
Change-Id: Ib8ac742eb97359be47e1ff01ae6f10518761a302
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2144452
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
When code raises an Objective-C exception, unwind the stack looking for
any exception handlers. If an exception handler is encountered, test to
see if it is a function known to be a catch-and-rethrow 'sinkhole'
exception handler. Various routines in UIKit and elsewhere do this, and
they obscure the exception stack, since the original throw location is
no longer present on the stack (just the re-throw) when Crashpad
captures the crash report. In the case of sinkholes, trigger an
immediate exception to capture the original stack.
The is an improvement over the alternative,
NSSetUncaughtExceptionHandler, which passes along the stack frames, but
not the stack memory contents and full exception context itself.
The details of what happens after a fatal exception is triggered are
unresolved in this CL. For now, simply call std::terminate.
This code was inspired by chromium/src/chrome/browser/mac/
exception_processor.mm.
Bug: crashpad:31
Change-Id: Ieebc6476a0507c466c8219c10f790ec0a624e58c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2125254
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Gather most of the necessary information for the exceptions snapshot.
Note that:
- The 'capture' portion of this CL will be moved out of the snapshot
interface and into a separate in-process dump to disk location.
- All of the pointer dereferences need to be wrapped in vm_read.
- The read-fast-and-dump logic in thread_snapshot may end up in a
different file completely, but until we pick a
serialization/deserialization method, keep it as-is.
Bug: crashpad:31
Change-Id: Iae4af436cddabd2302689b76c8a4574eb8e48c0e
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2098744
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Gather most of the necessary information for the system snapshot.
Note that:
- The 'capture' portion of this CL will be moved out of the snapshot
interface and into a separate in-process dump to disk location.
- All of the pointer dereferences need to be wrapped in vm_read.
- The read-fast-and-dump logic in thread_snapshot may end up in a
different file completely, but until we pick a
serialization/deserialization method, keep it as-is.
Bug: crashpad:31
Change-Id: Iac82491fdb4a823163f02149f52a1e18e26fa9de
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2090173
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Gather most of the necessary information for the module snapshot.
Note that:
- The 'capture' portion of this CL will be moved out of the snapshot
interface and into a separate in-process dump to disk location.
- All of the pointer dereferences need to be wrapped in vm_read.
- The read-fast-and-dump logic in module_snapshot may end up in a
different file completely, but until we pick a
serialization/deserialization method, keep it in module_snapshot_ios.
Change-Id: Ie80c739c167634520d13ec920a29a80116aa3bfe
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2079196
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
First steps at bringing up the crashpad_client on iOS. Also updates
the XCUITest to trigger various crashes, with some swizzling
necessary to allow crashes.
Change-Id: I87dd36bed1c052b509d14bfa29679ed81e58a377
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2039470
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Note that upload consent is ignored if --use-cros-crash-reporter is
present, which it will be if invoked by Chrome on ChromeOS.
BUG=chromium:1037656
TEST=None
Change-Id: I2dcea736de40a082b477f21d46c3ed01f1d91699
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2042317
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Ian Barkley-Yeung <iby@chromium.org>
This CL adds code to check if the current thread holds the DLL loader
lock. This code can be used to enforce the requirement that certain
parts of crashpad, such as process creation are not done during calls
to DllMain which can lead to deadlocks and crashes. Only one check is
current enforced, in client process creation, and only in debug builds.
Bug: crashpad: 316
Change-Id: I5757a264bbf28ce2ab88a0cd7ac9481e46428c17
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1945993
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: James Forshaw <forshaw@chromium.org>
Since gtest 00938b2b228f, gtest has built-in first-class support for
skipping tests, which is functionally identical (at least in Crashpad’s
usage) to the home-grown support for run-time dynamically disabled tests
introduced in Crashpad 5e9ed4cb9f69.
Use the new standard pattern, and remove all vestiges of the custom
local one.
This was done previously in 79f4a3970a64, but was reverted in
bba9d0819c12 because Chromium’s test launcher did not support
GTEST_SKIP() at the time. The deficiency is on file as
https://crbug.com/912138.
While that bug was never specifically marked as “fixed” and I haven’t
found what changed in Chromium, I do now see some use of GTEST_SKIP() in
Chromium. I also prototyped this change in Chromium at
https://chromium-review.googlesource.com/c/1854691/ and found that
GTEST_SKIP() does indeed now appear to work.
Change-Id: I13fef8fe8bfd9854a40dfa5910a3282d1a85bc45
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1855380
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
HandlerMain() consumes argv[0] as the name for itself. Arguments
before the class name are consumed by app_process when using a Java
handler. Re-insert app_process for HandlerMain() to consume as the
program name or else it will consume the next real argument.
Bug: chromium:1011145
Change-Id: Id7090db36cc382a9fdba49b9259dbbce3a9bcc5c
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1841974
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
It turns out it's frequently convenient to only grab one of these at a time.
Change-Id: Ie4a05583a5c875163154efc485d57a014101cc16
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1838011
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
The metrics recording signal handler doesn't need to be re-installed
on Linux because the handler installed by StartHandler() restores the
previously installed handler by default. Reinstalling the metrics
handler results in a crash dump loop in which each signal handler
restores the other.
Change-Id: Ieef40c74bfc69f6e0caef9809f33cfcaa10f0d03
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1832153
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
These methods are used to connect additional clients to an existing
handler process.
Bug: crashpad:285
Change-Id: Iefa5b0d8f5fd7d4799140ff9a7c2f79ac65da738
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1759281
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
client_win used a non-standard/poorly defined "Acquire Store" and
"Release Load" pair to have handlers notify when they changed
state and to wait for handlers to change state. Acquire stores
and Release Loads are not expressable in C++11 atomics and even at
face value did not provide useful semantics here (code waiting for a
handler to change state wants to see the handler's stores.)
Change-Id: I8d08d0d7baf9979406557ec2b90fea4cd51892bc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1741716
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Removes the remaining references to the old port-based exception APIs in
favor of the new channel-based APIs.
Bug: fuchsia:ZX-4031
Test: runtests on emulator and device
Change-Id: Ieac5b66c2f676966d1018d771cab6c8635f12a8f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1700321
Reviewed-by: Francois Rousseau <frousseau@google.com>
Commit-Queue: Francois Rousseau <frousseau@google.com>
This is very similar to the windows implementation in
module_snapshot_win.cc.
Bug: crashpad:95
Change-Id: I3858e8bb0009c95395bfb7ca3855c3d937fd49d5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1641588
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This CL adds a RequestCrashDumpHandler to request a crash dump over a
socket. Common functionality with LaunchAtCrashHandler is factored out
into a SignalHandler base class.
Bug: crashpad:284
Change-Id: I86293ef599a0dd6eea63c096a5c931c620c05ecc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1568985
Reviewed-by: Mark Mentovai <mark@chromium.org>
sendmsg() and recvmsg() are complicated to use. Refactor their usage
into functions with a simpler, tested interface and use those instead.
This also adds CreateCredentialSocketpair() to create a pair of
connected sockets with SO_PASSCRED set. This option should be set
before the possibility of any calls to sendmsg() with the socket pair
to avoid race conditions in properly setting credentials.
Also update the handler to use Strategy::kNoPtrace (which causes the
crash dump to fail without breaking the socket connection) if the
credentials were invalid, which can happen if SO_PASSCRED was set after
the call to sendmsg() or if the sending process does not exist in this
namespace.
Change-Id: Id09f87125540255687a3c35d5bed7fa01ec07cff
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1584639
Reviewed-by: Mark Mentovai <mark@chromium.org>
Multi client socket connections allow multiple clients to request crash
dumps from a handler process using a single, shared socket connection.
This connection mode does not support using a broker process which
requires a dedicated socket connection to ensure handler messages
aren't intercepted by the wrong clients.
The handler uses SIGCONT to indicate to the crasher when a crash dump
is complete (or has failed) and may continue.
Bug: crashpad:284
Change-Id: I2031029cd254f17497cbf7e7d8740c289581e8aa
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1559306
Reviewed-by: Mark Mentovai <mark@chromium.org>
This patch adds the class ExceptionHandlerProtocol to contain all the
relevant types, but should not make any functional changes.
Change-Id: I65ada239a6bf3195899fdd96f005c042cdd59749
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1575796
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
When sampling has disabled crash reporting for WebView, no signal
handler is initialized, causing later calls to DumpWithoutCrash()
to crash.
Bug: 949295
Change-Id: Ib93986f81bc83404ac9f4d8f40fb34e54f1b3bec
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1558817
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
apparently we're attempting to log to a C++ out-stream during process exit, and that is causing the run-time to try to do a character-set conversion, requiring it to look up some run-time locale state which has presumably already been torn-down
Bug: chromium:948588
Change-Id: I9431dafd0aaaa8827faf3b24985873733b431e22
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1558812
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>
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>
today the attachments are not taken into account, but should on Linux and Fuchsia
Bug: fuchsia:DX-1104
Tested:`fx run-test crashpad_test` for Fuchsia.
Change-Id: I022331bdb09c637f40ff2ba2d711e301e211e86a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1518323
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
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>
This reverts commit 79f4a3970a6425ef0475263974bf9a012279ba4f.
Chromium’s test launcher is not prepared to handle GTEST_SKIP().
Bug: chromium:912138
Change-Id: Iaeffaedcd92093ec61b013f2a919dc4670094581
Reviewed-on: https://chromium-review.googlesource.com/c/1464099
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Since gtest 00938b2b228f3, gtest has built-in first-class support for
skipping tests, which is functionally identical (at least in Crashpad’s
usage) to the home-grown support for run-time dynamically disabled tests
introduced in Crashpad 5e9ed4cb9f69.
Use the new standard pattern, and remove all vestiges of the custom
local one.
Change-Id: Ia332136c356d523885fc5d86bc8f06fefbe6a792
Reviewed-on: https://chromium-review.googlesource.com/c/1427242
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@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>
Crashpad client testing no longer addresses an element of a possibly-
empty array.
Change-Id: I434b4b8c462894d8241b810973e1b4a87d1851ba
Reviewed-on: https://chromium-review.googlesource.com/c/1376375
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
* the call to LoggingRemoveFile wrapped ina DCHECK is actually only executed in debug mode :-(
* found the issue using zxdb!
Bug: fuchsia:DX-344
Bug: crashpad:217, crashpad:196
Change-Id: I5332a17ccffd94b9bad8c61831adb797bd53a13d
Tested:`crasher` on device
Reviewed-on: https://chromium-review.googlesource.com/c/1364452
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Francois Rousseau <frousseau@google.com>
This code was merged from chromium commit:
6a2d5519c69e195e584055b186789b7f760c9703
Implement crashpad support for GCPW
- Implements crashpad support for GCPW installer
- Implements crashpad support for the actual credential provider dll
and runs the crashpad handler directly in the dll as an entry point
Bug: 890348
Change-Id: I5b256b4d6ad8ee7153fd22e4d13f1a1791fa6d65
Reviewed-on: https://chromium-review.googlesource.com/c/1344210
Commit-Queue: Tien Mai <tienmai@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611187}
Message-Id: Merged from chromium 6a2d5519c69e195e584055b186789b7f760c9703
Reviewed-on: https://chromium-review.googlesource.com/c/1358731
Commit-Queue: Scott Graham <scottmg@chromium.org>
This is a reland of 95e97a32eba4d505ab9591e683d2147c441eea48
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Bug: crashpad:260
Change-Id: I66713de84cc26c9119e0454d19c9c189263fe054
Reviewed-on: https://chromium-review.googlesource.com/c/1318066
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This reverts commit 95e97a32eba4d505ab9591e683d2147c441eea48.
Reason for revert: arm64 lto build
Original change's description:
> Use a relative address in .note.crashpad.info
>
> The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
> from desc.
>
> Making this note writable can trigger a linker error resulting in
> the binary embedding .note.crashpad.info to be rejected by the
> kernel during program loading.
>
> The error was observed with:
> GNU ld (GNU Binutils for Debian) 2.30
> clang version 4.0.1-10 (tags/RELEASE_401/final)
> Debian 4.17.17-1rodete2
>
> When the note is made writable, crashpad_snapshot_test contains two
> PT_LOAD segments which map to the same page.
>
> LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000258 0x0000000000000258 R 0x200000
> LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
> 0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
>
> Executing this binary with the execv system call triggers a segfault
> during program loading (an error can't be returned because the original
> process vm has already been discarded).
>
> I suspect (I haven't set up a debuggable kernel) the failure occurs
> while attempting to map the second load segment because its virtual
> address, 0x258, is in the same page as the first load segment.
> https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
>
> The linker normally produces consecutive load segments where the second
> segment is loaded 0x200000 bytes after the first, which I think is the
> maximum expected page size. Modifying the test executable to load the
> second segment at 0x1258 (4096 byte page size) allows program loading
> to succeed (but of course crashes after control is given to it).
>
> Bug: crashpad:260
> Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
> Reviewed-on: https://chromium-review.googlesource.com/c/1292232
> Reviewed-by: Scott Graham <scottmg@chromium.org>
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Joshua Peraza <jperaza@chromium.org>
TBR=scottmg@chromium.org,jperaza@chromium.org,mark@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: crashpad:260
Change-Id: I7a2c741e6b4c10d3e3b8be3213a8ce2cd93675f7
Reviewed-on: https://chromium-review.googlesource.com/c/1316372
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
The desc value in the note is now the offset of CRASHPAD_INFO_SYMBOL
from desc.
Making this note writable can trigger a linker error resulting in
the binary embedding .note.crashpad.info to be rejected by the
kernel during program loading.
The error was observed with:
GNU ld (GNU Binutils for Debian) 2.30
clang version 4.0.1-10 (tags/RELEASE_401/final)
Debian 4.17.17-1rodete2
When the note is made writable, crashpad_snapshot_test contains two
PT_LOAD segments which map to the same page.
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000258 0x0000000000000258 R 0x200000
LOAD 0x0000000000000258 0x0000000000000258 0x0000000000000258
0x00000000002b84d8 0x00000000002b8950 RWE 0x200000
Executing this binary with the execv system call triggers a segfault
during program loading (an error can't be returned because the original
process vm has already been discarded).
I suspect (I haven't set up a debuggable kernel) the failure occurs
while attempting to map the second load segment because its virtual
address, 0x258, is in the same page as the first load segment.
https://elixir.bootlin.com/linux/v4.17.17/source/fs/binfmt_elf.c#L380
The linker normally produces consecutive load segments where the second
segment is loaded 0x200000 bytes after the first, which I think is the
maximum expected page size. Modifying the test executable to load the
second segment at 0x1258 (4096 byte page size) allows program loading
to succeed (but of course crashes after control is given to it).
Bug: crashpad:260
Change-Id: I2b9f1e66e98919138baef3da991a9710bd970dc4
Reviewed-on: https://chromium-review.googlesource.com/c/1292232
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@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>
When a renderer crashes in Multi-process WebView, the browser process
may need to crash itself to maintain equivalent behavior with single
process WebView. This allows it to do so without generating a dump of
the browser process, which would provide no useful information.
Change-Id: I272d6322269bd0ba8753b5b3959a613877eaf867
Reviewed-on: https://chromium-review.googlesource.com/c/1258082
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These methods use /system/bin/app_process{32,64} to load a Java class
supplied by the embedding application. It is expected that the
supplied class loads a native library containing Crashpad's handler
code and passes its arguments to crashpad::HandlerMain().
Bug: crashpad:30
Change-Id: Ic0f9a1439007047b06f07f5ec7d5de9a9d4a19a2
Reviewed-on: https://chromium-review.googlesource.com/1194400
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This will be useful to allow setting variables such as CLASSPATH or
LD_LIBRARY_PATH without modifying or depending upon the application's
current environment.
Bug: crashpad:30
Change-Id: I34f31bcc397e51d789b48eb654d80f992a719074
Reviewed-on: https://chromium-review.googlesource.com/1194399
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
mcgrathr points out in https://chromium-review.googlesource.com/1172090
that std::random_shuffle is deprecated in C++14 and removed in C++17.
Rather than having mini_chromium mimic Chromium’s base by providing
RandomShuffle (Chromium 5de2157f1e7f), just use the standard library’s
std::shuffle with mt19937(random_generator).
Change-Id: I8c2b3101bf324350351dba9edda1ba230b1c6710
Reviewed-on: https://chromium-review.googlesource.com/1176122
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This worked before because getopt also accepts prefixes of known
options.
Change-Id: I0a479ad17954c541e84dc77230abcff19e8fae72
Reviewed-on: https://chromium-review.googlesource.com/1173439
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
These fixes are mostly related to address sanitizer causing stack
variables to not be stored on the call-stack. Attempting to disable
safe-stack has no effect.
Change-Id: Ib5718bfb74ce91dee560b397ccdbf68d78e4ec6a
Reviewed-on: https://chromium-review.googlesource.com/1140507
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is more direct than using an out-parameter. Copy elision should
make it equally performant, and even in the absence of copy elision,
this would now be an inexpensive move operation.
Change-Id: Iaf0eb07b36c8e35ff8942fc422a22321bf5c3010
Reviewed-on: https://chromium-review.googlesource.com/1145495
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Also includes a gtest roll, which includes a change in gtest to do the
same thing. This also removes the link against launchpad which is no
longer necessary, and will be removed from the SDK soon.
Bug: crashpad:196, chromium:848028, chromium:850757
Change-Id: Ica8632a6157b585d6b44073e05bf7aa43253e305
Reviewed-on: https://chromium-review.googlesource.com/1096353
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@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>
Rather than using liblaunchpad.so to create processes, we now use
fdio_spawn.
Bug: crashpad:196
Change-Id: I28a7c12c823f0a0d120962edfce2e2197302b9cb
Reviewed-on: https://chromium-review.googlesource.com/1080234
Commit-Queue: Scott Graham <scottmg@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>
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>
Annotations data structures may be dynamically allocated so could
appear outside a modules's address range. Let ImageAnnotationReader
use a ProcessMemoryRange for the process, rather than the module.
Also add a test for linux.
Bug: crashpad:30
Change-Id: Ibbf1d2fcb2e44b1b70c8a02e86c6f2fbd784535f
Reviewed-on: https://chromium-review.googlesource.com/1054705
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
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>
Of course, as soon as I tried it against the real endpoint on Fuchsia,
the server just spits out raw crash id as a string without specifying
Content-Length.
Bug: crashpad:196, crashpad:30
Change-Id: I22af87589a8801cdfece0a7b862e70e0e7097f1f
Reviewed-on: https://chromium-review.googlesource.com/1024953
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This allows clients to use the database to handle uploads themselves,
e.g. on Android, where Crashpad does not yet provide an uploader.
The handler does not launch an upload thread when no url is supplied.
Previously, the handler would move these reports to
completed and record the upload as skipped with kUploadsDisabled.
With this change, these reports would remain pending until pruned,
with no metrics recorded for them in regard to their upload.
Bug: crashpad:30
Change-Id: I4167ab1531634b10e91d03229018ae6aab4103aa
Reviewed-on: https://chromium-review.googlesource.com/1010970
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
uc_mcontext.fpregs is a pointer to the floating point context, but
CaptureContext() doesn't yet capture floating point context.
This error manages to slip by unit tests when run all together, but
fails when CrashpadClient.SimulateCrash is run by itself.
Bug: crashpad:30
Change-Id: I7adc30648642912d66a7ba8cf9973c9bc0fbd8bc
Reviewed-on: https://chromium-review.googlesource.com/1011504
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
client_argv_handling.{cc,h} were added to BUILD.gn, but omitted from
the corresponding gyp files.
Change-Id: I52ebf61234cfa22c3f08e2edd824c298e4879e6a
Reviewed-on: https://chromium-review.googlesource.com/1010921
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
I plan to have Fuchsia use a "StartHandlerAtCrash" style similar to
Linux, so pull the argv preservation out into a location where it can be
shared between crashpad_client_linux.cc and crashpad_client_fuchsia.cc
(in upcoming sets).
Bug: crashpad:196
Change-Id: Ie305556579d9ac2c97b205ecf63cadf069228811
Reviewed-on: https://chromium-review.googlesource.com/1002860
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
build/build_config.h sometimes includes other headers which aren't
appropriate for .S files.
Bug: crashpad:30
Change-Id: Ie039e08599137d157c60482c72d6eba6a5566ef5
Reviewed-on: https://chromium-review.googlesource.com/966876
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Google Test has recently switched the default death test style from
"fast" to "threadsafe". This is a better default, and Chrome will adopt
it on all platforms except for Android.
In threadsafe mode, the death test in
client/simple_string_dictionary_test.cc consistently crashes with the
wrong expectation on Mac. Fortunately, breaking the test up into two
smaller tests makes the failures go away, and also adds a bit of clarity
into what is being tested.
Bug: crashpad:221
Change-Id: I2416647948815cfe46a003da8209af8b7278de2a
Reviewed-on: https://chromium-review.googlesource.com/936043
Commit-Queue: Victor Costan <pwnall@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This ensures the symbol is not exposed in the binaries final symbol
table. .globl needs to be kept so that it can still be linked against
(in this case, by crashpad_info.cc.).
(Tested on Fuchsia, hopefully functional elsewhere...)
Bug: crashpad:196
Change-Id: I8c6b26cdd742a1c040779884fd97a8a34068dbdc
Reviewed-on: https://chromium-review.googlesource.com/924337
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Fuchsia does not currently support any sort of file locking. Until a
lock server can be implemented, compile out the calls to flock(). In the
one current non-test user of locking (Settings) add a
pseudo-implementation that will DCHECK if there is ever contention on
the lock.
Bug: crashpad:217, crashpad:196
Change-Id: Ifdf7e00886ad7e7778745f1ae8f0ce2a86f0ae3b
Reviewed-on: https://chromium-review.googlesource.com/924312
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These tests needed to be updated to expose CrashpadInfo in the same way
as the main CrashpadInfo g_crashpad_info is found on
Linux/Android/Fuchsia.
Unfortunately, while the tests pass on Fuchsia when run in isolation,
the implementation of dlclose() on Fuchsia currently does nothing. So,
if the full test suite is run, there's interference between the test
modules (i.e. the values in _small vs. the values in _large), so the
tests fail.
I filed ZX-1728 upstream about this to see if it might be implemented,
or if the test will need to spawn a clean child to do the module load
tests in.
Bug: crashpad:196
Change-Id: I9ee01b142a29c508c6967dc83da824afa254d379
Reviewed-on: https://chromium-review.googlesource.com/923182
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Fuchsia errors out in rename() when source == dest. I believe this is
incorrect according to
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html,
but it's also relatively easy to work around in our code, and this fixes
CrashReportDatabaseTest.RequestUpload.
This is ZX-1729 upstream.
Bug: crashpad:196
Change-Id: I27473183b04484e146a7bd9e87e60be3aeff1932
Reviewed-on: https://chromium-review.googlesource.com/923708
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Placing a 32-bit pointer directly into a .quad results in either an
unsupported relocation error at link time (ARM) or an inability to
load the executable (x86).
Also, only attempt to read a module's CrashpadInfo if an info address
note was found.
Change-Id: I053af3d77eed70af66248be88547656d2b29878a
Reviewed-on: https://chromium-review.googlesource.com/922397
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
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>
Embeds the address of g_crashpad_info into a .note section (which is
readable by the generic code to read notes in ElfImageReader).
Unfortunately because the note section is in libclient.a, it would
normally be dropped at link time. To avoid that, GetCrashpadInfo() has
a reference *back* to that section, which in turn forces the linker to
include it, allowing the note reader to find it at runtime.
Previously, it was necessary to have the embedder of "client" figure out
how to cause `g_crashpad_info` to appear in the final module's dynamic
symbol table. With this new approach, there's no manual configuration
necessary, as it's not necessary for the symbol to be exported.
This is currently only implemented in the Linux module reader (and I
believe the current set of enabled tests aren't exercising it?) but it
will also be done this way for the Fuchsia implementation of
ModuleSnapshot.
Bug: crashpad:196
Change-Id: I599db5903bc98303130d11ad850ba9ceed3b801a
Reviewed-on: https://chromium-review.googlesource.com/912284
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
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>
Pulled out of jperaza's https://crrev.com/c/689745.
Future updates to the CrashReportDatabase would like to be decide on the
Settings location later than the constructor, but still keep the Settings
object embedded inline. To allow this, pass the location FilePath in
Initialize() rather than to the constructor.
Bug: crashpad:206
Change-Id: I8792188314541f6fd0bd04b168d22f8e445bc187
Reviewed-on: https://chromium-review.googlesource.com/916533
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, the mac version was under client/ and win under util/win/.
This cl brings them all together under util/misc/ and combines common
test code.
Bug: crashpad:30
Change-Id: Idf0d0158b969d5aa9802dfc8c21f73041b2bcc6c
Reviewed-on: https://chromium-review.googlesource.com/907755
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
In setting up the gn build, slightly different optimization settings
were applied for release builds. This caused a couple things to happen,
1) the sketchy noinline declspec was ignored, and 2) the distance
between reading the IP and the actual crash exceeded the tolerance of 64
bytes in the parent.
To make the test more robust to this, use CaptureContext() (I think our
improved version didn't exist at the time the tests was originally
written). Also, switch from crashpad::CheckedWriteFile to Windows'
WriteFile(), which avoids inlining a whole lot of code at that point.
The return value is not checked, but the next thing that happens is that
the function crashes unconditionally, so this does not seem like a huge
problem.
Bug: crashpad:79
Change-Id: I8193d8ce8b01e1533c16b207813c36d6d6113d89
Reviewed-on: https://chromium-review.googlesource.com/902693
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Responsibility for creating argv_c has moved to DoubleForkAndExec().
Change-Id: Id663f0597ee1749df564cdacac1d877b5545750b
Reviewed-on: https://chromium-review.googlesource.com/898024
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
This change includes methods to install a signal handler to launch
the handler process at crash time or to launch the handler on behalf
of another process.
Bug: crashpad:30
Change-Id: I503c788cb3648852d09e9e8c1fe5099ca07a0277
Reviewed-on: https://chromium-review.googlesource.com/759406
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@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>
This allows brace initializing a C array of StringAnnotation objects.
Bug: crashpad:192
Change-Id: Id1b187b67b24bb57251957e9d9c18c16579f1dd4
Reviewed-on: https://chromium-review.googlesource.com/807645
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@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>
This avoids relying on set_sources_assignment_filter, and so gets closer
to a correct set of files to build on Fuchsia.
Bug: crashpad:79, crashpad:196
Change-Id: Ib7daa5137935113c6645b72eb1dedd943a9db96e
Reviewed-on: https://chromium-review.googlesource.com/797672
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>
In Chromium, the AnnotationList is registered in the main executable
module. However, when using the component build, the individual shared
libraries do not explicitly initialize the CrashpadInfo nor
AnnotationList. This causes annotations to NULL-dereference the
uninitialized AnnotationList when using the component build.
By using the Register method instead, the AnnotationList will be lazily
created. In Chromium's static/release build, the AnnotationList will
still be initialized deterministically during startup.
Bug: crashpad:192
Change-Id: I8599b52630f4d7608e5028b14264a8eed49a9176
Reviewed-on: https://chromium-review.googlesource.com/793981
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
I have no idea if this will work as not much is building yet, but it
seems plausible for the time being.
Bug: crashpad:196
Change-Id: Ie3a358512a968e9e777ed03c0bffc5e273a0f12e
Reviewed-on: https://chromium-review.googlesource.com/786777
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@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>
Crashpad has many tests that crash intentionally. Some of these are
gtest death tests, and others arrange for intentional crashes to test
Crashpad’s own crash-catching logic. On macOS, all of the gtest death
tests and some of the other intentional crashes were being logged by
ReportCrash, the system’s crash reporter. Since these reports
corresponded to intentional crashes, they were never useful, and served
only to clutter ~/Library/Logs/DiagnosticReports.
Since Crashpad is adept at handling exceptions on its own, this
introduces the “exception swallowing server”,
crashpad_exception_swallower, which is a Mach exception server that
implements a no-op exception handler routine for all exceptions
received. The exception swallowing server is established as the task
handler for EXC_CRASH and EXC_CORPSE_NOTIFY exceptions during gtest
death tests invoked by {ASSERT,EXPECT}_DEATH_{CHECK,CRASH}, and for all
child processes invoked by the Multiprocess test infrastructure. The
exception swallowing server is not in effect at other times, so
unexpected crashes in test code can still be handled by ReportCrash or
another crash reporter.
With this change in place, no new reports are generated in the
user-level ~/Library/Logs/DiagnosticReports or the system’s
/Library/Logs/DiagnosticReports during a run of Crashpad’s full test
suite on macOS.
Bug: crashpad:33
Change-Id: I13891853a7e25accc30da21fa7ea8bd7d1f3bd2f
Reviewed-on: https://chromium-review.googlesource.com/777859
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@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>
The handler will now be less strict about checking CrashpadInfo struct
sizes. Assuming the signature and version fields match:
- If the handler sees a struct smaller than it’s expecting, the module
was likely built with an earlier version of the client library, and
it’s safe to treat the unknown fields as though they were zero or
other suitable default values.
- If the handler sees a struct larger than it’s expecting, the module
was likely built with a later version of the client library. In that
case, actions desired by the client will not be performed, but this
is not otherwise an error condition.
The CrashpadInfo struct must always be at least large enough to contain
at least the size field. The signature and version fields are always
checked.
The section size must be at least as large as the size carried within
the struct. To account for possible section padding, strict equality is
not required.
Bug: chromium:784427
Test: crashpad_snapshot_test CrashpadInfoSizes_ClientOptions/*.*
Change-Id: Ibb0690ca6ed5e7619d1278a68ba7e893d55f19fb
Reviewed-on: https://chromium-review.googlesource.com/767709
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This introduces the Annotation object, used to declare typed
annotations, and the AnnotationList object, used to reference these. The
AnnotationList is referenced by the CrashpadInfo structure. Currently
nothing reads these.
The AnnotationList implements a lock-free linked list, into which
Annotation objects are added exactly once, when they are first set.
Clearing an Annotation merely marks it internally as such, rather than
removing it from the list.
Bug: crashpad:192
Change-Id: I72414b1f83d624c4ae323e09ecea8cfb69a68c5e
Reviewed-on: https://chromium-review.googlesource.com/547135
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@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>
CrashpadClient::DumpAndCrashTargetProcess() suspends the target process
and injects a thread to raise an exception. The injected thread is not
suspended, and may proceed to the point that the system recognizes the
process as terminating by the time the overall process suspension is
lifted. Previously, if this happened, an extraneous error was logged for
the attempt to resume a terminating process.
This introduces “termination tolerance” to ScopedProcessSuspend, which
allows an object to be configured to ignore this error and not log any
messages when this condition is expected.
This resolves log messages such as this one, produced frequently during
calls to CrashpadClient::DumpAndCrashTargetProcess() (including in
end_to_end_test.py):
> [pid:tid:yyyymmdd,hhmmss.mmm:ERROR scoped_process_suspend.cc:39]
> NtResumeProcess: An attempt was made to access an exiting process.
> (0xc000010a)
0xc000010a = STATUS_PROCESS_IS_TERMINATING
Test: end_to_end_test.py
Change-Id: Iab4c50fb21adce5502080ad25a6f734ec566d65c
Reviewed-on: https://chromium-review.googlesource.com/700715
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
The binary crashpad_handler.com is used by crashpad_client_win_test.cc,
but is not currently built when building crashpad_client_test.
Bug: crashpad:
Change-Id: I7a440774e49be9e821bca57c154a67b968a4bfbd
Reviewed-on: https://chromium-review.googlesource.com/695832
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
To enable clang-cl's printf format string mismatch checking, a few
mismatch errors need to be fixed where DWORD (unsigned long) is printed
with %u, %d or %x (an 'l' is needed).
Change-Id: I2cbfafe823a186bfe3a555aec3a7ca03e85466f8
Reviewed-on: https://chromium-review.googlesource.com/598651
Commit-Queue: Xi Cheng <chengx@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is essentially based on a search for “^const .*=”.
Change-Id: I9332c1f0cf7c891ba1ae373dc537f700f9a1d956
Reviewed-on: https://chromium-review.googlesource.com/585452
Reviewed-by: Leonard Mosescu <mosescu@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>
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>
In the 10.12 SDK, x86_state_hdr from <mach/i386/thread_status.h> was
defined as:
struct x86_state_hdr {
int flavor;
int count;
};
This has changed in the 10.13 SDK to:
struct x86_state_hdr {
uint32_t flavor;
uint32_t count;
};
This triggers signedness mismatch errors where these values are used
with CHECK/DCHECK macros and gtest EXPECT/ASSERT macros.
Compatibility with existing and new SDKs must be maintained, so more
casts must be used.
Bug: crashpad:185, crashpad:188
Change-Id: I8844d6a78520430a8b5b90a35403896c3c6cfa37
Reviewed-on: https://chromium-review.googlesource.com/533375
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
I opted to leave casts to types that were definitely the same size
alone. reinterpret_cast<uintptr_t>(pointer) and
reinterpret_cast<intptr_t>(pointer) should always be safe, for example.
Casts to other integral types have been replaced with
FromPointerCast<>(), which does zero-extension or sign-extension based
on the target type.
To make it possible to use FromPointerCast<>() with some use sites that
were already using checked_cast<>(), FromPointerCast<>() now uses
check_cast<>() when converting to a narrower type.
Test: crashpad_util_test FromPointerCast*, others
Change-Id: I4a71b4aa2d87f545c75524290a702f5f3138d675
Reviewed-on: https://chromium-review.googlesource.com/489701
Reviewed-by: Scott Graham <scottmg@chromium.org>
Includes mini_chromium ef0ded8717340c9fe48e8e0f34f3e0e74d10a392.
1d2a024fdb1d android: Use _FILE_OFFSET_BITS after all (undo
dc3d480305b2)
ef0ded871734 win: MSVS 2017 (15)/C++ 14.1/C 19.10 compatibility
Change-Id: I5c814669a0ef8577872bddff9112ce28ec628ba3
Reviewed-on: https://chromium-review.googlesource.com/482639
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
TerminateProcess(), like most of the Windows API, is declared WINAPI,
which is __stdcall on 32-bit x86. That means that the callee,
TerminateProcess() itself, is responsible for cleaning up parameters on
the stack on return. In https://crashpad.chromium.org/bug/179, crashes
in ExceptionHandlerServer::OnNonCrashDumpEvent() were observed in ways
that make it evident that TerminateProcess() has been patched with a
__cdecl routine. The crucial difference between __stdcall and __cdecl is
that the caller is responsible for stack parameter cleanup in __cdecl.
The mismatch means that nobody cleans parameters from the stack, and the
stack pointer has an unexpected value, which in the case of the Crashpad
handler crash, results in TerminateProcess()’s second argument
erroneously being used as the lock address in the call to
ReleaseSRWLockExclusive() or LeaveCriticalSection().
As a workaround, on 32-bit x86, call through SafeTerminateProcess(), a
custom assembly routine that’s compatible with either __stdcall or
__cdecl implementations of TerminateProcess() by not trusting the value
of the stack pointer on return from that function. Instead, the stack
pointer is restored directly from the frame pointer.
Bug: crashpad:179
Test: crashpad_util_test SafeTerminateProcess.*, others
Change-Id: If9508f4eb7631020ea69ddbbe4a22eb335cdb325
Reviewed-on: https://chromium-review.googlesource.com/481180
Reviewed-by: Scott Graham <scottmg@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>
gtest used to require (expected, actual) ordering for arguments to
EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify
each side as “expected” or “actual.” Tests in Crashpad adhered to this
traditional ordering. After a gtest change in February 2016, it is now
agnostic with respect to the order of these arguments.
This change mechanically updates all uses of these macros to (actual,
expected) by reversing them. This provides consistency with our use of
the logging CHECK_EQ and DCHECK_EQ macros, and makes for better
readability by ordinary native speakers. The rough (but working!)
conversion tool is
https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py,
and “git cl format” cleaned up its output.
EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made
a judgment that one side or the other needed to provide an “unexpected”
value. Consequently, some code used (unexpected, actual) while other
code used (actual, unexpected). For consistency with the new EXPECT_EQ
and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE,
this change also updates these use sites to (actual, unexpected) where
one side can be called “unexpected” as, for example, std::string::npos
can be. Unfortunately, this portion was a manual conversion.
References:
https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison77d6b17338https://github.com/google/googletest/pull/713
Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3
Reviewed-on: https://chromium-review.googlesource.com/466727
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>
Bug: crashpad:81
Change-Id: I3cb115440638df909d1c0cdfd01c824ac0d0b073
Reviewed-on: https://chromium-review.googlesource.com/458592
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Previously on macOS, the test used an OS-specific library function to
recover the original argc and argv. On Linux/Android, it essentially
reimplemented the very code it was testing, which didn’t make for a very
good test. The new approach is to save argc and argv in main() and base
the comparison on that.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*, crashpad_test_test MainArguments.*
Change-Id: I578abed3b04ae10a22f79a193bbb8b6589276c97
Reviewed-on: https://chromium-review.googlesource.com/456798
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@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>
