--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>
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>
Provides Read, ReadCString, and ReadCStringSizeLimited. Does not provide
ReadMapped because Linux does not support mmap on /proc/pid/mem.
Bug: crashpad:30
Change-Id: Ia319c0107b1f138aeb8e5d0ee480c77310df7202
Reviewed-on: https://chromium-review.googlesource.com/459700
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@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>
mig-generated server dispatch routines used to not clear this field in
reply messages prepared from request messages. This oversight was
corrected in the migcom in bootstrap_cmds-96 (macOS 10.12 and Xcode
8.0). Maybe someone at Apple saw the admonishing comment that we had
left here. This comment can now be removed.
Change-Id: I73d965705a2ff5788afb59dd8ecdf4afe58ee47e
Reviewed-on: https://chromium-review.googlesource.com/465687
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This also enhances ScopedMmapDeathTest.Mprotect to better ensure that
ScopedMmap::Mprotect() works properly.
Bug: crashpad:30
Test: crashpad_util_test ScopedMmap*.*
Change-Id: Iff35dba9fa993086f3f4cd8f4a862d802e637bb1
Reviewed-on: https://chromium-review.googlesource.com/464547
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
It should be possible to shrink a region already supervised by
ScopedMmap, or in rare cases when ScopedMmap is supervising only a
smaller portion of an overall larger region, increase the size of the
region it supervises. This is now equivalent to the operation of
base::mac::ScopedMachVM::reset().
The Reset() and ResetAddrLen() methods are upgraded from a void return
to a bool return to indicate their success.
Bug: crashpad:30
Test: crashpad_util_test ScopedMmap*.ResetAddrLen_*
Change-Id: I564e154cd2387e8df3f83b416ecc1c83c9bcf71d
Reviewed-on: https://chromium-review.googlesource.com/464286
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Use test::Multiprocess, which ensures that waitpid() is called to reap
child processes.
Previously, after a several thousand iterations (using --gtest_repeat),
fork() would begin failing with EAGAIN:
[ RUN ] ProcessInfo.Forked
../../util/posix/process_info_test.cc:165: Failure
Expected: (pid) >= (0), actual: -1 vs 0
fork: Resource temporarily unavailable (35)
[ FAILED ] ProcessInfo.Forked (0 ms)
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.Forked
Change-Id: Ia95c9297d5eeb02894f58844ced1b50981870cbc
Reviewed-on: https://chromium-review.googlesource.com/461482
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This makes it easier to generate Doxygen documentation on Windows.
Change-Id: I14c203d2618d8321d5a94d836de434bbaa21c3c9
Reviewed-on: https://chromium-review.googlesource.com/461403
Reviewed-by: Scott Graham <scottmg@chromium.org>
macOS 10.12.4 includes an updated timezone database. Abbreviations for
Australia/Eucla (formerly ACWST, now +0845) and Australia/Lord_Howe
(formerly LHST/LHDT, now +1030/+11) were dropped in IANA TZ 2017a. The
test is updated so that the abbreviations for these two time zones are
no longer checked.
References:
a25d615495https://mm.icann.org/pipermail/tz/2017-February/024837.html
Test: crashpad_snapshot_test SystemSnapshotMacTest.TimeZone
Change-Id: I2845c6aee7b7b6a8fcdc6faa4d5cefe5e0f72e5c
Reviewed-on: https://chromium-review.googlesource.com/461500
Reviewed-by: Scott Graham <scottmg@chromium.org>
The Bug: style (a Gerrit footer) is used by git-cl for Gerrit changes as
of 3a16ed155e3f.
Bug: chromium:681184
Change-Id: I58c29b6908aee57c7f03374180148f241af91b22
Reviewed-on: https://chromium-review.googlesource.com/461481
Reviewed-by: Scott Graham <scottmg@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>
Checking child process’ exit codes would have helped catch bug
crashpad:160 sooner. Instead, we had a flaky hang that was difficult to
reproduce locally.
Bug: crashpad:160
Test: crashpad_snapshot_test ExceptionSnapshotWinTest.ChildCrash*:ProcessSnapshotTest.CrashpadInfoChild*:SimulateCrash.ChildDumpWithoutCrashing*, crashpad_util_test ProcessInfo.OtherProcess
Change-Id: I73bd2be1437d05f0501a146dcb9efbe3b8e0f8b7
Reviewed-on: https://chromium-review.googlesource.com/459039
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>
The use of InterlockedCompareExchange() was very wrong. Improved error
checking coming in another CL from mark@, see linked bug for discussion.
Bug: crashpad:160
Change-Id: Id230af6f37c6cdce807dd4d8aba9d33e9bdeffd0
Reviewed-on: https://chromium-review.googlesource.com/459230
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This code that works out the name of the CPU being built for is most
likely going to move out to be used more generally and for Android. It
should nail down the CPU name correctly when possible. Previously,
32-bit x86 always showed up as “i686” and 32-bit ARM always showed up as
“armv7l”.
Bug: crashpad:30
Change-Id: Ifd4b91f30062f5ef621a166f77a732dd8a88a58e
Reviewed-on: https://chromium-review.googlesource.com/458118
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Previously, the __ANDROID_API__ macro was provided by
<android/api-level.h>. With unified headers (expected to become the
default in the next NDK release and the sole option in the subsequent
release), this macro is not set properly by headers. When building with
Clang, the standalone toolchain’s clang and clang++ wrappers set the
macro properly. GCC isn’t accounted for in this way, so the build system
must assume the responsibility of setting it.
This change fishes the value of __ANDROID_API__ out of the standalone
toolchain’s clang wrapper and sets the android_api_level GYP variable
appropriately. From there, it will be picked up by common.gypi in
mini_chromium and used to define __ANDROID_API__.
This updates mini_chromium to 62e6015f633dd4acb1610db15a064889315cadaa
which understands this new GYP variable.
62e6015f633d android: Support “unified headers” with GCC build
https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.mdhttps://android.googlesource.com/platform/ndk/+/ndk-r14/CHANGELOG.md
Bug: crashpad:30
Change-Id: I33e66eba8394e32ced8dca80c8226b85e0e786f3
Reviewed-on: https://chromium-review.googlesource.com/458021
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
NDK r13 and earlier provided a bogus definition of OPEN_MAX, but it was
removed from NDK r14 effective in a future API level. It is also not
available when using a standalone toolchain with unified headers.
ff5f17bc8a
Bug: crashpad:30
Change-Id: Ic89d6879cb1a4e5b9d20e9cb06bedd5176df0f2a
Reviewed-on: https://chromium-review.googlesource.com/458121
Reviewed-by: Scott Graham <scottmg@chromium.org>
While compiling minidump_module_writer_test.cc:
minidump/minidump_module_writer_test.cc: In member function 'virtual void crashpad::test::{anonymous}::MinidumpModuleWriter_InitializeFromSnapshot_Test::TestBody()':
minidump/minidump_module_writer_test.cc:656:15: error: variable 'module_names' set but not used [-Werror=unused-but-set-variable]
const char* module_names[arraysize(expect_modules)] = {};
^
Bug: crashpad:30
Change-Id: Ie6bcbced67c947ba6cca32a7057a8ac6de4d0e5a
Reviewed-on: https://chromium-review.googlesource.com/457958
Reviewed-by: Scott Graham <scottmg@chromium.org>
These were previously fixed in f83530bf9a0b for some targets, but not
crashpad_minidump_test.
While compiling minidump_misc_info_writer_test.cc:
In file included from minidump/minidump_misc_info_writer.h:26:0,
from minidump/minidump_misc_info_writer_test.cc:15:
minidump/minidump_misc_info_writer_test.cc: In member function ‘virtual void crashpad::test::{anonymous}::MinidumpMiscInfoWriter_TimeZone_Test::TestBody()’:
minidump/minidump_misc_info_writer_test.cc:401:39: error: cannot bind packed field ‘expected.MINIDUMP_MISC_INFO_3::TimeZone.TIME_ZONE_INFORMATION::StandardName’ to ‘short unsigned int (&)[32]’
arraysize(expected.TimeZone.StandardName));
~~~~~~~~~~~~~~~~~~^
third_party/mini_chromium/mini_chromium/base/macros.h:41:50: note: in definition of macro ‘arraysize’
#define arraysize(array) (sizeof(ArraySizeHelper(array)))
^~~~~
Bug: crashpad:30
Change-Id: I2a1c3b356c0064e8161ec70a9ac156053fc28df7
Reviewed-on: https://chromium-review.googlesource.com/457881
Reviewed-by: Scott Graham <scottmg@chromium.org>
This was already addressed by disabling a warning, but was only
effective for macOS and non-Android Linux. The comment for the existing
fix, which is now being applied to Android:
> The MOCK_METHODn() macros do not specify “override”, which triggers
> this warning in users: “error: 'Method' overrides a member function
> but is not marked 'override'
> [-Werror,-Winconsistent-missing-override]”. Suppress these warnings,
> and add -Wno-unknown-warning-option because only recent versions of
> clang (trunk r220703 and later, version 3.6 and later) recognize it.
Also see https://crbug.com/428099.
The errors being encountered since 3983b80ca2fc were:
util/file/file_reader_test.cc:48:23: error: 'Read' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
FileOperationResult Read(void* data, size_t size) {
^
util/file/file_reader.h:39:31: note: overridden virtual function is here
virtual FileOperationResult Read(void* data, size_t size) = 0;
^
util/file/file_reader_test.cc:53:16: error: 'Seek' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
MOCK_METHOD2(Seek, FileOffset(FileOffset, int));
^
util/file/file_seeker.h:31:22: note: overridden virtual function is here
virtual FileOffset Seek(FileOffset offset, int whence) = 0;
^
Bug: crashpad:30
Test: crashpad_util_test FileReader.*
Change-Id: I10894efdafc0da965e3780219f2e4c1f13f9b99e
Reviewed-on: https://chromium-review.googlesource.com/458060
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Use an underscore instead of a hyphen in the overview design doc’s
filename for consistency with the rest of the files in the repository.
Change-Id: I15a76a00709a43dfec60e7f4f6ee64a3cd031b2c
Reviewed-on: https://chromium-review.googlesource.com/458537
Reviewed-by: Sigurður Ásgeirsson <siggi@chromium.org>
952f787f4aab missed two occurrences that should have been updated.
Change-Id: I425367689eb19edfd309a2210a79ed400e190673
Reviewed-on: https://chromium-review.googlesource.com/458116
Reviewed-by: Robert Sesek <rsesek@chromium.org>
file_io and the FileReader family had a few loose ends regarding big
reads and writes. It’s not likely that we’ve experienced these
conditions yet, but they’d be likely to appear in a potential future
involving full memory dumps. This specifies the behavior with large
reads and writes, consolidates some logic, and improves some interfaces.
ReadFile() should always return without retrying after a short read, and
in fact does return after short reads since 00b64427523b. It is
straightforward to limit the maximum read size based on a parameter
limitation of the underlying operation, or a limitation of the type used
for FileOperationResult.
In contrast, WriteFile() should always retry after a short write,
including a write shortened because of a parameter limitation of the
underlying operation, or a limitation of the type used for
FileOperationResult. This allows its return value to be simplified to a
“bool”.
The platform-specific WriteFile() code has been moved to
internal::NativeWriteFile(), and the platform-independent loop that
retries following a short write has been refactored into
internal::WriteAllInternal so that it can be used by a new test.
The platform-agnostic ReadFileExactlyInternal() implementation has been
refactored into internal::ReadExactlyInternal so that it can be used by
a new test and by FileReaderInterface::ReadExactly(), which had a nearly
identical implementation.
Test: crashpad_util_test FileIO.ReadExactly_*:FileIO.WriteAll_*:FileReader.ReadExactly_*
Change-Id: I487450322ab049c6f2acd4061ea814037cc9a864
Reviewed-on: https://chromium-review.googlesource.com/456824
Reviewed-by: Scott Graham <scottmg@chromium.org>
This is co-dependent with
https://chromium-review.googlesource.com/457736.
I’ve been trying to share a source tree between different platforms,
using gyp_crashpad.py --generator-output to put the build output in the
right place. On Windows, it winds up in
out\win\out\{Debug,Release}{,_x64}. This makes it tricky to use
run_tests.py, which expects to find build output right in the “out”
directory. It’s not impossible to use, because you can tell it
“win\out\Debug_x64”, but it’s really awkward to use that path when we
all know that it’s not relative to anything that makes sense, like the
current directory.
This simplifies run_tests.py to work directly with the
configuration-specific output directory. For most users, this means
including “out/” or “out\” when running the script.
Bug: chromium:703890
Change-Id: Ic7de82fabd2adda7ae00558844cb3ce91aa4a5ed
Reviewed-on: https://chromium-review.googlesource.com/457716
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
After b10d9118dea4, the MemoryListStream was moved from its preferred
position as the last stream in the file to precede user minidump
streams, in an effort to prevent it from being preempted by a user
minidump stream that specified the memory list stream’s type. A better
solution, which keeps all streams where they want to be, is to put the
MemoryListStream at the end, put user streams before it, and omit user
streams that purport to be a MemoryListStream.
Bug: crashpad:171
Change-Id: I6974fbd4c9ec67284f86c593c553af7adf73601b
Reviewed-on: https://chromium-review.googlesource.com/456823
Reviewed-by: Sigurður Ásgeirsson <siggi@chromium.org>
WorkDelegate::DoWork() can be called more times than the value set by
WorkDelegate::SetDesiredWorkCount(). The main test thread may not be
able to “squeeze” its call to WorkerThread::Stop() in after its
WorkDelegate::WaitForWorkCount() returns. If the worker thread cannot be
stopped in time, one or more additional iterations of
WorkDelegate::DoWork() can run. WorkDelegate::DoWork() should take care
to not increment work_count_ beyond the desired value.
Bug: crashpad:169
Test: crashpad_util_test WorkerThread.*
Change-Id: I9e261a2a8a57420e12c0f1c9abd0ee6304dacd53
Reviewed-on: https://chromium-review.googlesource.com/456821
Reviewed-by: Robert Sesek <rsesek@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>
With GCC 6.3:
util/file/file_io_posix.cc: In function ‘crashpad::FileHandle crashpad::StdioFileHandle(crashpad::StdioStream)’:
util/file/file_io_posix.cc:193:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
Bug: crashpad:30
Change-Id: I03111b672ab7f796103ef61ea3d126fc25571390
Reviewed-on: https://chromium-review.googlesource.com/456820
Reviewed-by: Robert Sesek <rsesek@chromium.org>
These classes were a bit of a hack, and one of the the reasons that
WeakStdioFileReader was introduced, accurate detection of EOF when stdin
is a terminal, will be obsolete once
https://chromium-review.googlesource.com/456676/ lands. In fact,
WeakStdioFileReader didn’t even work properly for this purpose on
Windows.
Use WeakFile{Reader,Writer} in place of these classes (there were only
two use sites). Provide a StdioFileHandle() function to access the
proper values to use as a FileHandle for native file I/O given each OS’
own interface.
Change-Id: I35e8d49982162bb9813855f41739cc77597ea74d
Reviewed-on: https://chromium-review.googlesource.com/456358
Reviewed-by: Robert Sesek <rsesek@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>
This implements a non-stdio-based getline() equivalent. getline() is not
in the Android NDK until API 21 (Android 5.0.0), while Chrome builds for
32-bit platforms with API 16 (Android 4.1.0). Although a getline()
declaration could be provided in compat for use with older NDK headers,
it’s desirable to move away from stdio entirely. The C++
DelimitedFileReader interface is also a bit more comfortable to use than
getline().
A getdelim() equivalent is also provided, and is also used in the
Linux/Android ProcessInfo implementation.
Bug: crashpad:30
Test: crashpad_util_test FileLineReader.*:ProcessInfo.*
Change-Id: Ic1664758a87cfe4953ab22bd3ae190761404b22c
Reviewed-on: https://chromium-review.googlesource.com/455998
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
The unconditional CHECK() in MinidumpFileWriter::AddStream() made sense
when all streams were under the Minidump class family’s control, but
became hazardous upon the introduction of user streams with arbitrary
types under the crashy process’ control.
Bug: crashpad:171
Test: crashpad_minidump_test MinidumpFileWriter.SameStreamType
Change-Id: Iba5be08b330261286d11d22d8e9a2fef5fcc1070
Reviewed-on: https://chromium-review.googlesource.com/456056
Reviewed-by: Sigurður Ásgeirsson <siggi@chromium.org>
The new Linux ProcessInfo implementation uses two macros not readily
available in NDK API versions older than 21 (Android 5.0.0): NT_PRSTATUS
and PR_GETREGSET.
Chrome uses API 21 for 64-bit builds, but uses API 16 for 32-bit builds.
NT_PRSTATUS is normally defined by <elf.h> or by <linux/elf.h>, included
by <elf.h>. Although the definition in <linux/elf.h> is available in
older NDK API versions, this internal header does not mix well with
<elf.h> unless <elf.h> contemplates this combination. As of NDK API 21,
<elf.h> actually delegates most of its work to <linux/elf.h>.
PR_GETREGSET is not available in the NDK at all until API 21. Its
definition is in <linux/ptrace.h>. Most user code should #include
<sys/ptrace.h> instead, which includes <linux/ptrace.h>.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: I4d07a9964db4665a49bde490e905ae9126880bc5
Reviewed-on: https://chromium-review.googlesource.com/455659
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The PTRACE_GETREGSET ptrace() request is not supported on ARM before
Linux 3.5.0. This request was only used to determine the bitness of the
target process. Since 64-bit ARM is only supported as of Linux 3.7.0,
when this request is not supported on 32-bit ARM, 64-bit is also not
supported, and the target process must be a 32-bit process.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: Ib004d24858f146df898dfa6796926d97e2510541
Reviewed-on: https://chromium-review.googlesource.com/455398
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Not all libc implementations reliably expose pt_regs from
<sys/ptrace.h>. glibc-2.25/sysdeps/generic/sys/ptrace.h, for example,
does not #include <asm/ptrace.h> (which defines the structure) or
anything else that would #include that file such as <linux/ptrace.h>. On
the other hand, Android 7.1.1 bionic/libc/include/sys/ptrace.h does
#include <linux/ptrace.h>.
It is not viable to #include <asm/ptrace.h> or <linux/ptrace.h>
directly: it would be natural to #include them, sorted, before
<sys/ptrace.h> but this causes problems for glibc’s <sys/ptrace.h>.
Constants like PTRACE_GETREGS and PTRACE_TRACEME are simple macros in
<asm/ptrace.h> and <linux/ptrace.h>, respectively, but are defined in
enums in glibc’s <sys/ptrace.h>, and this doesn’t mix well. It is
possible to #include <asm/ptrace.h> (but not <linux/ptrace.h>) after
<sys/ptrace.h>, but because this involves same-value macro redefinitions
and because it reaches into internal headers, it’s not preferred.
The alternative approach taken here is to use the user_regs structure
from <sys/user.h>, which is reliably defined by both Bionic and glibc,
and has the same layout as the kernel’s pt_regs structure. (All that
matters in this code is the size of the structure.) See Android 7.1.1
bionic/libc/include/sys/user.h,
glibc-2.25/sysdeps/unix/sysv/linux/arm/sys/user.h, and
linux-4.9.15/arch/arm/include/asm/ptrace.h for the various equivalent
definitions.
Take the same approach for 64-bit ARM: use user_regs_struct from
<sys/user.h> in preference to hoping for a C library’s <sys/ptrace.h> to
somehow provide the kernel’s user_pt_regs.
This mirrors the approach already being used for x86 and x86_64, which
use the C library’s <sys/user.h> user_regs_struct.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: I3067e32c7fa4d6c8f4f2d5b63df141a0f490cd13
Reviewed-on: https://chromium-review.googlesource.com/455558
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Lazy initialization is particularly beneficial for Is64Bit(), which uses
a different (ptrace()-based) approach than the rest of the class (which
is /proc-based). It is possible for the /proc-based Initialize() to
succeed while ptrace() would fail, as it typically would in the
ProcessInfo.Pid1 test. Because this test does not call Is64Bit(),
permission to ptrace() shouldn’t be necessary, and in fact ptrace()
shouldn’t even be called.
This enables the ProcessInfo.Pid1 test on Android (due to ptrace(), it
was actually failing on any Linux, not just Android). It also enables
the ProcessInfo.Forked test on non-Linux, as the prctl(PR_SET_DUMPABLE)
Linux-ism can be removed from it.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: Ic883733a6aed7e7de9a0f070a5a3544126c7e976
Reviewed-on: https://chromium-review.googlesource.com/455656
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
The process start time in ticks was being converted to an integer from a
temporary string that had gone out of scope by the time the conversion
was performed.
It was possible for a format error in /proc/pid/stat to go undetected
and result in a buffer overflow.
Bug: crashpad:30
Change-Id: I03566dda797bc1f23543bfffcfdb2c5ffe1eca66
Reviewed-on: https://chromium-review.googlesource.com/455378
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This configuration uses user_regs_struct, which is declared in
<sys/user.h>.
Bug: crashpad:30
Change-Id: Ibdcc60c6719fc2bad9fbeef116efbe764229e14b
Reviewed-on: https://chromium-review.googlesource.com/455197
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
NDK 14 is current. Update the developer documentation to reflect this.
Recommend using subdirectories of out/ as the Android build output
directory, so that they’ll be ignored by .gitignore.
Bug: crashpad:30
Change-Id: Id1508215b924a3e0cae2c11a61c9c685363c50f6
Reviewed-on: https://chromium-review.googlesource.com/454202
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This requires depot_tools 57c4721d81da or later. Run “gclient” to
update.
When git-cl opens an editor for a change description that doesn’t
already have a bug line, the default bug line will now be a “Bug:
crashpad:” git footer field.
git footers are a more Gerrit-y way of handling things. It didn’t make
sense to have two distinct metadata footer sections (or more, if they
wound up interleaved). Standardize on the newer format. Bye-bye, BUG=.
Change-Id: I7dade51703f9eff471a49510793d37686ce5fc97
Reviewed-on: https://chromium-review.googlesource.com/452557
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Apple has responded to their bug 29079442 with a resolution stating that
these are not corpse ports but task ports that have changed after
execve(), as part of the large task port and execve() strategy rewrite
from 10.12.1. The comments being replaced were written before we had
10.12.1 source code. Now that we can see what’s going on, revise the
comments, and re-enable the task port check for the non-execve() test
variants.
https://openradar.appspot.com/29079442https://googleprojectzero.blogspot.com/2016/10/taskt-considered-harmful.html
Bug: crashpad:137
Test: crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld
Change-Id: I463637816085f4165b92b85a5b98bfeddcdf4094
Reviewed-on: https://chromium-review.googlesource.com/451120
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
crashpad_http_upload sends HTTP POST multipart/form-data requests and
receives responses in exactly the same manner that crashpad_handler does
for crash report uploads, but separates it out for more general testing
and debugging.
Change-Id: I5c5919f9b1dc1e6be1e43b15a35b31f51add8a46
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>
MINIDUMP_MISC_INFO_5 can carry information about extended XSTATE state
components and the process cookie value.
I made some informed guesses about the precise meanings of some of the
attributes of the XSTATE stuff.
I don’t know what “process cookie” refers to yet. My guess is that it’s
the stack canary value, or something similar. But since this isn’t an
informed guess, I haven’t written it into the documentation.
Crashpad does not yet use either of these features.
BUG=crashpad:58
Change-Id: I614568287a01fec99d6cd60e378a6d6e20b4f48c
Reviewed-on: https://chromium-review.googlesource.com/409630
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
For perceived freshness of command-line tools.
Change-Id: I835c2d116d2b5d4d654149a9d6d790a4fb8e253f
Reviewed-on: https://chromium-review.googlesource.com/448202
Reviewed-by: Scott Graham <scottmg@chromium.org>
crashpad_util should already have been the target to depend on
version.lib, but this wasn’t caught until something that depends on
crashpad_util but not crashpad_snapshot used that code, as
crashpad_util_test now does.
Change-Id: I1b7ced72c657946b297a328c0f89f51190d7d708
Reviewed-on: https://chromium-review.googlesource.com/448203
Reviewed-by: Scott Graham <scottmg@chromium.org>
Previously, macOS used “User-Agent: crashpad_util_test (unknown version)
CFNetwork/807.2.14 Darwin/16.4.0 (x86_64)” and Windows gave results like
“User-Agent: Crashpad/0.8.0”.
Now, macOS uses “User-Agent: Crashpad/0.8.0 CFNetwork/807.2.14
Darwin/16.4.0 (x86_64)” and Windows uses “User-Agent: Crashpad/0.8.0
WinHTTP/10.0.14393.351 Windows_NT/10.0.14393.0 (x64)”
Change-Id: I578b44734cf59d79e3d9b6136b4b92f05acefe71
Reviewed-on: https://chromium-review.googlesource.com/447796
Reviewed-by: Robert Sesek <rsesek@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>
Includes an update of mini_chromium to 3a2d52d74c9a:
3a2d52d74c9a Use O_CLOEXEC (and O_NOCTTY) when calling open()
BUG=chromium:688362
Change-Id: I2bdf86efe4e6559ecb77492ac5bdc728aa035889
Reviewed-on: https://chromium-review.googlesource.com/447999
Reviewed-by: Scott Graham <scottmg@chromium.org>
This will make “git cl format” work in Crashpad on Linux.
BUG=crashpad:30
Change-Id: I3f356b46d93707419a229ae40b1387bb7629bb39
Reviewed-on: https://chromium-review.googlesource.com/448056
Reviewed-by: Mark Mentovai <mark@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>
As I was finishing d98a4de718d9, it became evident that fsave
proliferation was becoming a problem. Especially considering tests,
there was much duplicated conversion code. This ties everything up
together in a central location.
test::BytesToHexString() is a new function to ease testing of byte
arrays like x87 registers, without having to loop over each byte.
Some static_asserts are added to verify that complex structures that
need to maintain interoperability don’t grow or shrink. This is used
to check the size of the fxsave and fsave structures, as well as the
MinidumpCPUContext* structures.
BUG=crashpad:162
Change-Id: I1a1be18096ee9be250cbfb2e006adfd08eba8753
Reviewed-on: https://chromium-review.googlesource.com/444004
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>
When no SSE (fxsave) context is available but x87 (fsave) context is, use the
x87 context.
This also embeds the x87 FPU opcode from the fxsave fop field in bits 16-26 of
the fsave error_selector field, true to the layout of the fsave structure. See
Intel SDM volume 1 (253665-061) 8.1.10 and figure 8-9.
BUG=crashpad:161
TEST=crashpad_snapshot_test CPUContextX86.*:CPUContextWin.*
Change-Id: I0bf7ed995c152f124166eaa20104d228d3468f76
Reviewed-on: https://chromium-review.googlesource.com/442144
Reviewed-by: Scott Graham <scottmg@chromium.org>
In the HTTPTransport test, verify the requirement of RFC 7230 §3.3.2
that Content-Length not appear if Transfer-Encoding is present.
TEST=crashpad_util_test HTTPTransport.*
BUG=crashpad:159
Change-Id: I51eafff9659443e1d9bb67d1213c8cecc757ded6
Reviewed-on: https://chromium-review.googlesource.com/439984
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Chunked encoding doesn’t require the length of the request body to be
known in advance. In cases where this value isn’t independently known,
as is normal for Crashpad report uploads where the HTTP request body is
constructed on the fly, chunked encoding eliminates the need to prepare
the entire request body in memory before transmitting it. In these
cases, it’s much less wasteful.
When the length of the request body is known in advance, based on the
provision of a Content-Length header, chunked encoding is not used.
Even so, the request is sent in pieces rather than reading the entire
request into memory before sending anything.
BUG=crashpad:159
TEST=crashpad_util_test HTTPTransport.*
Change-Id: Iebb2b63b936065cb8c3c4a62b58f9c14fec43937
Reviewed-on: https://chromium-review.googlesource.com/439644
Reviewed-by: Scott Graham <scottmg@chromium.org>
BUG=crashpad:158
Change-Id: If8666140a7fc5315eeb791d0998226de89a22cc3
Reviewed-on: https://chromium-review.googlesource.com/438791
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Remove stl_util from Crashpad. This also updates mini_chromium to
4f3cfc8e7c2b7d77f94f41a32c3ec84a6920f05d to remove stl_util from there
as well.
4f3cfc8e7c2b Remove stl_util from mini_chromium
BUG=chromium:555865
Change-Id: I8ecb1639a258dd233d524834ed205a4fcc641bac
Reviewed-on: https://chromium-review.googlesource.com/438865
Reviewed-by: Scott Graham <scottmg@chromium.org>
Update buildtools to a7cc7a3e21a061975b33dcdcd81a9716ba614c3c
adb8bf4e8fc9 Roll gn 4838fe571d..2eb03fab2b (r411399:r411754)
347c89790b42 Roll gn 2eb03fab2b..71c9ade4e9 (r411754:r415392)
82d2a28e425b Roll gn 2eb03fab2b..fe79dde87a (r411754:r415725)
b97d6c93a3e8 Roll gn 2eb03fab2b..764c7362bc (r411754:r417994)
6115afa0ea5e Roll gn 764c7362bc..668b150d14 (r417994:r419236)
f8088e3792a7 Roll gn 668b150d14..6a1c8d418d (r419236:r419720)
57649e5e2001 Roll gn 6a1c8d418d..65f3a42b24 (r419720:r419871)
86f7e41d9424 roll clang-format 258123:282138
3d2e47bf14e4 Fix repo url, remove recursion reference in DEPS
5fd66957f08b Roll gn 65f3a42b24..82dfb24218 (r419871:r421311)
39b1db2ab4aa Roll gn b6c1d4353b..bdc8e1e447 (r421341:r422996)
1f985091a586 Roll clang-format 0ed791d..6a413e9
991f459071f9 Roll gn bdc8e1e447..000b1184a0 (r422996:r432866)
102c16366d8b libc++: Don't pass -pthread to link.
64e38f0cebdd Roll gn 000b1184a0..78660e873f (r432866:r436326)
55ad626b08ef Roll gn 78660e873f..8897c835c2 (r436326:r436733)
0ef801087682 Roll gn 8897c835c2..c99acd6557 (r436733:r439377)
8932ecfa420a Roll gn c99acd6557..b1f498915e (r439377:r441559)
7e08d331f188 Roll gn c99acd6557..5c18ca83ce (r439377:r442253)
005cae407b97 Roll gn c99acd6557..7a3be23857 (r439377:r442631)
9a947138bc58 Roll gn 5c18ca83ce..7c0e0135f9 (r442253:r443802)
cb12d6e8641f Roll gn 7c0e0135f9..b4dbf044c5 (r443802:r443809)
8e94621c369e Roll gn b4dbf044c5..f13158d3c5 (r443809:r445411)
a7cc7a3e21a0 Roll gn f13158d3c5..d8754536ca (r445411:r446079)
Update mini_chromium to e504d59673e56887a4e837cbeb44b32ec21974f9
cae485daae70 win: Initial version of toolchain for GN
57f426502e00 Enable thread-safe statics when building with GCC and clang
e504d59673e5 Remove now-unused LazyInstance
Update gtest to d62d6c6556d96dda924382547c54a4b3afedb22c
9759dcda3c2f Fix compilation on MinGW with native threads
a138385e48ee Don't use pthread when on MinGW even if available
3429113886a9 Fix a test to compile when tuple isn't available
ed9d1e1ff92c Merge pull request #721 from ilmagico/fix-mingw-threads
d8fe70f477d8 Fix build with MinGW-w64
48ee8e98abc9 Merge pull request #856 from KindDragon/mingw-appveyor
10ff7f946863 Fixing relative links
16d6af7d414a Relative links
51b290d41e5d One works
9cb03aa70223 Fixing ForDummies link
f5c0130e88a3 Broken relative links fixed
995db996dee6 Fixing KnownIssues and FrequentlyAskedQuestions links
960a511f45be Fixing relative links
0e0ff5c3410f blob vs tree
32b4a9b39079 Fixed broken links
8ce0b5907cd9 Cookbok: fix broken relative link
ecd530865cef Merge pull request #876 from marco-m/patch-1
4eafafbde585 Fix detection of GTEST_HAS_CLONE for Android
3447fc31b4ee Merge pull request #728 from DanAlbert/tuple-stlport
a2b8a8e07628 Merge pull request #918 from
DanAlbert/fix-android-GTEST_HAS_CLONE
cb502b7ad15c Added CMake configure-time download instructions to docs
c0059a79f82d 2.6.4 is the minimum CMake version, so enforce it (#656)
5e7fd50e17b6 Merge pull request #658 from
audiofanatic/ExternalProject_at_configure_time
06a81e9357b6 Add GTEST_ATTRIBUTE_UNUSED_ to REGISTER_TYPED_TEST_CASE_P
3134af23d713 Merge pull request #1 from google/master
9ae086a9ebaf Merge pull request #874 from sejr/master
d62d6c6556d9 Merge pull request #982 from mbjorge/unused-variable-fix
Update gyp to a7055b3989c1074adca03b4b4829e7f0e57f6efd
702ac58e4772 Add new target type called windows_driver. * Modify GYP to
set the PlatformToolset, the DriverType and the
TargetVersion * Add msvs_target_version configuration
5dc5a5b1718e fix common "NameError"s
920ee58c3d31 Hash intermediate file name to avoid ENAMETOOLONG
ef2f29a7311b msvs: Allow target platform version without WinRT
940a15ee3f1c Update shared library extension on AIX to .a.
9733aa652da4 Set up a CQ for gyp
a7055b3989c1 Make Gerrit the default code review system for gyp
Change-Id: I11d8139b0f533911692dc7a11bb9edaddac78060
Reviewed-on: https://chromium-review.googlesource.com/438885
Reviewed-by: Scott Graham <scottmg@chromium.org>
In locations where daylight saving time was once observed or is expected
to be observed in the future, but where no transitions to or from
daylight saving time occurred or will occur within a year of the current
date, act as though DST is not being observed at all.
Set TZ=America/Phoenix to test for this bug.
BUG=crashpad:130
TEST=crashpad_snapshot_test SystemSnapshotMacTest.TimeZone
Change-Id: Ie466b5906eab3c0cf2e51b962a171acb5b16210b
Reviewed-on: https://chromium-review.googlesource.com/438004
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The 32-bit process_types definition of dyld_all_image_infos winds up
with four extra bytes of tail padding when built into a 64-bit
crashpad_handler compared to a 32-bit one, and compared to the
structure’s native size. This prevents a 64-bit crashpad_handler from
being able to create a module snapshot of a 32-bit process for
dyld_all_image_infos versions 14 (since 10.9) and 15 (since 10.12).
Work around this by placing a zero-length “end” marker and using
offsetof(dyld_all_image_infos, end) in preference to
sizeof(dyld_all_image_infos).
BUG=crashpad:156,crashpad:148,crashpad:120
TEST=crashpad_snapshot_test ProcessTypes.DyldImagesSelf,
run_with_crashpad --handler=crashpad_handler{,32} builtin_trap{,32}
Change-Id: I406ad53851b5bd29ec802b7ad3073836ebe8c34c
Reviewed-on: https://chromium-review.googlesource.com/437924
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>
Since it’s possible to receive an EXC_CRASH for any signal that
generates a core by default even if the signal did not originate from a
Mach exception, update the tests to ensure that all such signals can be
unwrapped from an exception properly. This happens when a signal such as
SIGSEGV is sent with kill(), for example.
Change-Id: I1ee32cc6943f21ae349fa6788430d074acff9ed8
Reviewed-on: https://chromium-review.googlesource.com/434717
Reviewed-by: Robert Sesek <rsesek@chromium.org>
With reference to 10.12 source, commentary regarding RESOURCE_TYPE_IO
can be authoritative.
Cursory examination of 10.12 source reveals that RESOURCE_TYPE_MEMORY
can now be fatal, although deeper examination reveals that this is
impossible on macOS. State this authoritatively as well.
BUG=crashpad:124
Change-Id: I52124c68fe017015983ab46e54006ba97ecd0142
Reviewed-on: https://chromium-review.googlesource.com/434297
Reviewed-by: Robert Sesek <rsesek@chromium.org>
After e7630628e9c9, I thought “isn’t there a standard library function
for that?” There is!
Change-Id: I284c7fdf8535c4fc53100e80fceb363bf2afee93
Reviewed-on: https://chromium-review.googlesource.com/431856
Reviewed-by: Scott Graham <scottmg@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>
Otherwise:
[2d68949...]D:\src\crashpad\crashpad>gn gen out\Debug
gn.py: Could not find gn executable at: D:\src\crashpad\buildtools\win\gn.exe
I have no idea why these binaries aren't just checked into buildtools,
but anyway.
BUG=crashpad:79
Change-Id: If2f21a7e7f795910809de7d3595ab6a5ffee9dc7
Reviewed-on: https://chromium-review.googlesource.com/424847
Reviewed-by: Mark Mentovai <mark@chromium.org>
This might feel a bit premature, but I feel fairly confident that basing
a lot of the processing on LLDB is the way to go, so I plan to start by
integrating it into our build process.
(I think probably moving from gyp to GN first makes sense, so I can defer
landing this until after that's farther along if you like.)
BUG=crashpad:29
Change-Id: I85ee44f4e777f9d7ce521c4caf10ead21ffd8818
Reviewed-on: https://chromium-review.googlesource.com/424910
Reviewed-by: Mark Mentovai <mark@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>
As brought up in https://codereview.chromium.org/2475863004/, there's
the potential for failed startup if StartHandlerProcess() hangs for
whatever reason. Add a timeout to the wait function so that this case
can attempt to log an error.
R=mark@chromium.org
BUG=655788, 656800, 565063
Change-Id: Ib08cd0641daa6a6cefabb773ffe470227b51958c
Reviewed-on: https://chromium-review.googlesource.com/419060
Reviewed-by: Mark Mentovai <mark@chromium.org>
