UBSan was reporting reference binding to a misaligned address in Fuchsia.
Disable UBSan for this target for now just to silence the runtime
warnings, then come back and fix them.
Bug: fuchsia:46805
Change-Id: Ic5d9b35161b6d998f1ff50eb8e978c44aff9b4ef
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2068051
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
- Add option to log minidump in handler_main, also add option to
disable to dump minidump and generate report.
- Implement log minidump in CrashReportExceptionHandler.
Bug: crashpad:308
Change-Id: I8d2f7e118912011a8416f1ec36c9ee9d561d06e6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1995825
Commit-Queue: Tao Bai <michaelbai@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Until now we've been stuffing ELF debug symbol link information into a
CodeViewPDB70. This has reached the limits of its usefulness. We now add
a CodeViewRecord that can contain a proper ELF build ID.
Change-Id: Ice52cb2a958a1b9031943f280d9054da02d2f17d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1574107
Commit-Queue: Casey Dahlin <sadmac@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is a follow-up to c8a016b99d97, following the post-landing
discussion at
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7
base::size, and std::size that will eventually replace it when C++17 is
assured, does not allow the size of non-static data members to be taken
in constant expression context. The remaining uses of ArraySize are in:
minidump/minidump_exception_writer.cc (×1)
minidump/minidump_system_info_writer.cc (×2, also uses base::size)
snapshot/cpu_context.cc (×4, also uses base::size)
util/misc/arraysize_test.cc (×10, of course)
The first of these occurs when initializing a constexpr variable. All
others are in expressions used with static_assert.
Includes:
Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao
f701716d9546 Add Windows ARM64 build target to mini_chromium
87a95a3d6ac2 Remove the arraysize macro
1f7255ead1f7 Placate MSVC in areas of base::size usage
737433ebade4 Add cast
Bug: chromium:837308
Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19
Reviewed-on: https://chromium-review.googlesource.com/c/1396108
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Add a method to ProcessSnapshotMinidump to expose a similar interface
to ModuleSnapshot::CustomMinidumpStreams(). It's implemented on the
process snapshot here because there is no way to map custom minidump
streams back to a specific module. This allows implementing tests that
inspect custom user streams in minidumps.
Bug: 896019
Change-Id: I1673c342753e13d64bddcc0083ca29fa356deac7
Reviewed-on: https://chromium-review.googlesource.com/c/1271405
Commit-Queue: Vlad Tsyrklevich <vtsyrklevich@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
re-enable once LUCI supports invalid UTF8 characters in test logs.
Bug: fuchsia:DX-487
Bug: chromium:872892
Bug: chromium:889582
Tested: /system/test/crashpad_tests on Fuchsia device
Change-Id: I3d6564423fb20554fdc39ffb7bd8e8bf7b1d3d48
Reviewed-on: https://chromium-review.googlesource.com/1251382
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
On Windows (and probably elsewhere) it's possible that something else on
the system changes the memory map between when a memory snapshot range
is added to the minidump, and when the process's memory is actually read
from the target and written to the .dmp file. As a result, failing the
Read() should not result in aborting the minidump's write, which it
previously would have.
Bug: crashpad:234
Change-Id: Ib24e255a34fa2e1758621d3955ebc7a0f96166e2
Reviewed-on: https://chromium-review.googlesource.com/1096452
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Mostly sensible implementation for x64 via cpuid. It's too early for
Fuchsia to have a version number, so nothing is reported for those
fields. ARM64 isn't implemented at all and would hit a lot of
NOTREACHED()s.
Bug: crashpad:196
Change-Id: I6ca8b12e16fe0cf773a17c88ca9d407b028a501c
Reviewed-on: https://chromium-review.googlesource.com/1005906
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
https://chromium-review.googlesource.com/c/chromium/mini_chromium/+/899847
turns the warning on. This adds one annotation, and fixes one bug.
Includes mini_chromium roll:
.../mini_chromium$ git log 5fcfa43c1587b94132e24782579350cb8266b990..3b953302848580cdf23b50402befc0ae09d03ff9 --oneline
3b95330 (HEAD, origin/master, origin/HEAD) Add -Wimplicit-fallthrough when building on clang
Bug: chromium:807632
Change-Id: I2f3ddca0228e52013844cb8d78d10cb359e851d0
Reviewed-on: https://chromium-review.googlesource.com/900317
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Follows https://chromium-review.googlesource.com/c/374019/.
Causes MinidumpMemoryListWriter to merge all overlapping ranges before
writing the MINIDUMP_MEMORY_LIST. This is:
1) Necessary for the Google internal crash processor, which in some
cases attempts to read the raw memory (displaying ASAN red zones),
and aborts if there are any overlapping ranges in the minidump on
load;
2) Necessary for new-ish versions of windbg (see bug 216 below). It is
believed that this is a change in behavior in the tool that made
dumps with overlapping ranges unreadable;
3) More efficient. The .dmp for crashy_program goes from 306K to 140K
with this enabled. In Chrome minidumps where
set_gather_indirectly_referenced_memory() is used (in practice this
means Chrome Windows Beta, Dev, and Canary), the savings are expected
to be substantial.
Bug: crashpad:61, chromium:638370, crashpad:216
Change-Id: I969e1a52da555ceba59a727d933bfeef6787c7a5
Reviewed-on: https://chromium-review.googlesource.com/374539
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Fuchsia builds with -Wmissing-field-initializers. Remove these {0}s. It
all seems a bit awful, but as far as I can tell from reading
http://en.cppreference.com/w/cpp/language/aggregate_initialization, the
0 is unnecessary.
../../third_party/crashpad/minidump/minidump_system_info_writer_test.cc:42:27: error: missing field 'Buffer' initializer [-Werror,-Wmissing-field-initializers]
MINIDUMP_STRING tmp = {0};
^
1 error generated.
Bug: crashpad:196
Change-Id: I21f48eb24238a607475b0e92ffe5fd88386b40b6
Reviewed-on: https://chromium-review.googlesource.com/833454
Commit-Queue: Scott Graham <scottmg@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>
Recent Clang versions started taking into account that enums are signed
on Windows when emitting these warnings.
Bug: chromium:792519
Change-Id: I08767fa1f5c8211e663769c7e76b13a1b7146f4f
Reviewed-on: https://chromium-review.googlesource.com/813497
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@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>
Bug: crashpad:196
Change-Id: I80c979967d95383e0f703a336a494f30ff583f1b
Reviewed-on: https://chromium-review.googlesource.com/786448
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
I ran the thing below (piped to “grep -v namespace”), fixed things up,
and rewrapped comments in the affected file.
import re
import sys
LAST_WORD_RE = re.compile('^.*[\s]+([\w]+)$')
FIRST_WORD_RE = re.compile('^[^\w]+([\w]+).*$')
for path in sys.argv[1:]:
with open(path) as file:
line_number = 0
last_word = None
for line in file:
line_number += 1
first_word = FIRST_WORD_RE.match(line)
if first_word and first_word.group(1) == last_word:
print('%s:%u: %s' % (path, line_number - 1, last_word))
last_word = LAST_WORD_RE.match(line)
if last_word:
last_word = last_word.group(1)
Change-Id: Iea9f2a6453d9d9ec17e2f238e09252535d7408bd
Reviewed-on: https://chromium-review.googlesource.com/780284
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: 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 warning suppression was recently added in a51e912004a6, and I don’t
know what I was thinking. I went out of my way to make it apply to both
Clang and GCC, but GCC doesn’t recognize this warning at all, nor does
it need any other warning suppressed.
Change-Id: I50341bfe81ee4799b3f6278d2e31ec31741952ac
Reviewed-on: https://chromium-review.googlesource.com/755654
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This writes any set annotation objects list for a module into a
minidump, though no crash handler currently sets annotation objects for
a crashing process.
Bug: crashpad:192
Change-Id: Ib6d92edecb8d40061eaee08cbbc5c20dd1f048ef
Reviewed-on: https://chromium-review.googlesource.com/744942
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This adds extensions for MinidumpAnnotation and MinidumpAnnotationList
as well as their writer classes. Nothing currently connects the client-
side annotations to the writer, so annotations are not yet written into
minidumps.
Bug: crashpad:192
Change-Id: Ic51536157177921640ca15ae14e5e01ca875ae12
Reviewed-on: https://chromium-review.googlesource.com/731309
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
While making crashpad_minidump_test run in Chromium’s try- and buildbots
(https://crbug.com/779790), crashes in the
MinidumpThreadWriter.OneThread_AMD64_Stack test were observed in 32-bit
x86 Windows builds produced by Clang in the release configuration. These
crashes occurred in crashpad::test::InitializeMinidumpContextAMD64,
which heap-allocates a MinidumpContextAMD64Writer object. These objects
have an alignment requirement of 16, based on the alignment requirement
of their MinidumpContextAMD64 member.
Although this problem was never observed with MSVC, Clang was making use
of the known strict alignment and producing code that depended on it.
This code crashed if the requirement was not met. MSVC had raised a
warning about this usage (C4316), but the warning was disabled as it did
not appear to have any ill effect on code produced by that compiler.
The problem surfaced in test code, but heap-allocated
MinidumpContextAMD64Writer objects are created in non-test code as well.
The impact is limited, because a 32-bit Windows Crashpad handler would
not have a need to allocate one of these objects.
As a fix, MinidumpContextAMD64Writer is given a custom allocation
function (a static “operator new()” member and matching “operator
delete()”) that returns properly aligned memory.
Change-Id: I0cb924da91716eb01b88ec2ae952a69262cc2de6
Reviewed-on: https://chromium-review.googlesource.com/746539
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
These are mostly -Wsign-compare warnings, with a -Wconstant-conversion
and a -Wunguarded-availability thrown in.
Bug: chromium:779790
Change-Id: Ic2103f3332ce57378db83eca7fa2569efec1a7b6
Reviewed-on: https://chromium-review.googlesource.com/746081
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
The MinidumpByteArray can be used to carry arbitrary blob payloads in a
minidump file.
Bug: crashpad:192
Change-Id: I1a0710b856375213cdd97eafa9247830aa9a9291
Reviewed-on: https://chromium-review.googlesource.com/716462
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>
Clang, GCC, and MSVS 2017 were fine with a “constexpr” definition
corresponding to a class-scope “static const” declaration, but MSVS 2015
is not.
Change-Id: I8c80c6e62d1a312bad161db98e584be225b70bbf
Reviewed-on: https://chromium-review.googlesource.com/592644
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>
Use the standard alignas instead of ALIGNAS in cases where this is
possible too. It’s not currently possible where ALIGNAS may be mixed
with other attributes, although the not-landed
https://codereview.chromium.org/2670873002/ suggests that where ALIGNAS
is mixed with __attribute__((packed)), it’s viable to write “struct
alignas(4) S { /* … */ } __attribute__((packed));”.
This includes an update of mini_chromium to
723e840a2f100a525f7feaad2e93df31d701780a, picking up:
723e840a2f10 Remove ALIGNOF
This tracks upstream https://codereview.chromium.org/2932053002/.
Change-Id: I7ddaf829020ef3be0512f803cecbb7c543294f07
Reviewed-on: https://chromium-review.googlesource.com/533356
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@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>
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>
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>
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>
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>
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>
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>
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>
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>
While compiling, for example, minidump_exception_writer.cc:
In file included from ../../minidump/minidump_exception_writer.h:26:0,
from ../../minidump/minidump_exception_writer.cc:15:
../../minidump/minidump_exception_writer.cc: In member function ‘void crashpad::MinidumpExceptionWriter::SetExceptionInformation(const std::vector<long unsigned int>&)’:
../../minidump/minidump_exception_writer.cc:67:44: error: cannot bind packed field ‘((crashpad::MinidumpExceptionWriter*)this)->crashpad::MinidumpExceptionWriter::exception_.MINIDUMP_EXCEPTION_STREAM::ExceptionRecord.MINIDUMP_EXCEPTION::ExceptionInformation’ to ‘long unsigned int (&)[15]’
arraysize(exception_.ExceptionRecord.ExceptionInformation);
~~~~~~~~~~~~~~~~~~~~~~~~~~~^
../../third_party/mini_chromium/mini_chromium/base/macros.h:41:50: note: in definition of macro ‘arraysize’
#define arraysize(array) (sizeof(ArraySizeHelper(array)))
Tested with:
- GCC 4.9 from NDK r13 targeting arm with SDK 16
- GCC 4.9 from NDK r13 targeting arm64 with SDK 21
- GCC 6.2 targeting x86_64
BUG=crashpad:30
Change-Id: I63963b277a309b4715148215f51902c33ba13b5a
Reviewed-on: https://chromium-review.googlesource.com/409694
Reviewed-by: Scott Graham <scottmg@chromium.org>
While compiling, for example,
minidump_simple_string_dictionary_writer.cc:
In file included from
../../minidump/minidump_module_crashpad_info_writer.cc:21:0:
../../minidump/minidump_simple_string_dictionary_writer.h:55:45: error:
declaration of ‘const crashpad::MinidumpSimpleStringDictionaryEntry*
crashpad::MinidumpSimpleStringDictionaryEntryWriter::MinidumpSimpleStringDictionaryEntry()
const’ [-fpermissive]
MinidumpSimpleStringDictionaryEntry() const;
^~~~~
In file included from
../../minidump/minidump_module_crashpad_info_writer.h:25:0,
from
../../minidump/minidump_module_crashpad_info_writer.cc:15:
../../minidump/minidump_extensions.h:255:26: error: changes meaning of
‘MinidumpSimpleStringDictionaryEntry’ from ‘struct
crashpad::MinidumpSimpleStringDictionaryEntry’ [-fpermissive]
struct ALIGNAS(4) PACKED MinidumpSimpleStringDictionaryEntry {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tested with:
- GCC 4.9 from NDK r13 targeting arm with SDK 16
- GCC 4.9 from NDK r13 targeting arm64 with SDK 21
- GCC 6.2 targeting x86_64
BUG=crashpad:30
Change-Id: I1e5e6a21a24f19eef7602e4123459ce15f3b089e
Reviewed-on: https://chromium-review.googlesource.com/409624
Reviewed-by: Robert Sesek <rsesek@chromium.org>
TEST=crashpad_minidump_test
MinidumpSystemInfoWriter.InitializeFromSnapshot_AMD64
Change-Id: I2fdd2061626a9f906eab025eeb8191d680196109
Reviewed-on: https://chromium-review.googlesource.com/409612
Reviewed-by: Scott Graham <scottmg@chromium.org>
This exposes a bit for PF_RDTSCP_INSTRUCTION_AVAILABLE in
CPU_INFORMATION::OtherCpuInfo::ProcessorFeatures. This bit was
introduced in Windows 10.
Change-Id: I464c308f8325d14c0839f609ea4260737a58f7a5
Reviewed-on: https://chromium-review.googlesource.com/409138
Reviewed-by: Scott Graham <scottmg@chromium.org>
This defines PROCESSOR_ARCHITECTURE_ARM64 and
PROCESSOR_ARCHITECTURE_ARM32_ON_WIN64, usable in
MINIDUMP_SYSTEM_INFO::ProcessorArchitecture.
This also defines four new PF_* flags usable in
CPU_INFORMATION::OtherCpuInfo::ProcessorFeatures.
Definitions are provided in compat/non_win, and #ifdef-guarded
definitions in compat/win for compatibility with Windows SDKs older than
Chrome’s minimum requirement.
PROCESSOR_ARCHITECTURE_ARM64 means the same thing that Breakpad used the
value 0x8003 for. At this point, Crashpad aims to use the
officially-defined constant. In the minidump_extensions.h
MinidumpCPUArchitecture enum, 0x8003 remains present and documented as
deprecated to discourage reuse of that constant for another purpose.
BUG=
Change-Id: Ic4b5fb9de31c5f00f3698f112633ece2a036b889
Reviewed-on: https://chromium-review.googlesource.com/409098
Reviewed-by: Scott Graham <scottmg@chromium.org>
This makes Doxygen’s output more actionable by setting QUIET = YES to
suppress verbose progress spew, and WARN_IF_UNDOCUMENTED = NO to prevent
warnings for undocumented classes and members from being generated. The
latter is too noisy, producing 721 warnings in the current codebase.
The remaining warnings produced by Doxygen were useful and actionable.
They fell into two categories: abuses of Doxygen’s markup syntax, and
missing (or misspelled) parameter documentation. In a small number of
cases, pass-through parameters had intentionally been left undocumented.
In these cases, they are now given blank \param descriptions. This is
not optimal, but there doesn’t appear to be any other way to tell
Doxygen to allow a single parameter to be undocumented.
Some tricky Doxygen errors were resolved by asking it to not enter
directiores that we do not provide documentation in (such as the
“on-platform” compat directories, compat/mac and compat/win, as well as
compat/non_cxx11_lib) while allowing it to enter the
“off-platform” directories that we do document (compat/non_mac and
compat/non_win).
A Doxygen run (doc/support/generate_doxygen.sh) now produces no output
at all. It would produce warnings if any were triggered.
Not directly related, but still relevant to documentation,
doc/support/generate.sh is updated to remove temporary removals of
now-extinct files and directories. doc/appengine/README is updated so
that a consistent path to “goapp” is used throughout the file.
Change-Id: I300730c04de4d3340551ea3086ca70cc5ff862d1
Reviewed-on: https://chromium-review.googlesource.com/408812
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Use “macOS” as the generic unversioned name of the operating system in
comments. For version-specific references, use Mac OS X through 10.6, OS
X from 10.7 through 10.11, and macOS for 10.12.
Change-Id: I1ebee64fbf79200bc799d4a351725dd73257b54d
Reviewed-on: https://chromium-review.googlesource.com/408269
Reviewed-by: Robert Sesek <rsesek@chromium.org>
ARCH_CPU_ARMEL, not ARCH_CPU_ARM. This is probably going to bite again.
BUG=crashpad:30
Change-Id: Ifa6069638c72db13b7f6498471f9ca3ad7c45b90
Reviewed-on: https://chromium-review.googlesource.com/406407
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This is as a precursor to
https://chromium-review.googlesource.com/374539 which merges
MemorySnapshots and so needs to be able to update them from the minidump
code.
MinidumpMemoryWriter existed to be able to mock for tests; that
behaviour is wrapped up in TestMemorySnapshot now.
BUG=crashpad:61, chromium:638370
Change-Id: I825ec57493b12fc1848018585c14544faa7e66d4
Reviewed-on: https://chromium-review.googlesource.com/374019
Reviewed-by: Mark Mentovai <mark@chromium.org>
The utilities in base/stl_util.h have been moved from the global
into the base namespace. This patch updates the call sites accordingly.
No functional changes.
Change-Id: I059d5d6299f947b1135672da170427d23ac4775e
Reviewed-on: https://chromium-review.googlesource.com/368640
Reviewed-by: Mark Mentovai <mark@chromium.org>
There’s no behavior change, but two variables that store quantities in
units of Hz were misnamed *_mhz.
Change-Id: I8b7d9576a7638a4ee9789dc9d1050009ac009696
Reviewed-on: https://chromium-review.googlesource.com/368080
Reviewed-by: Scott Graham <scottmg@chromium.org>
This was done in Chromium’s local copy of Crashpad in 562827afb599. This
change is similar to that one, except more care was taken to avoid
including headers from a .cc or _test.cc when already included by the
associated .h. Rather than using <stddef.h> for size_t, Crashpad has
always used <sys/types.h>, so that’s used here as well.
This updates mini_chromium to 8a2363f486e3a0dc562a68884832d06d28d38dcc,
which removes base/basictypes.h.
e128dcf10122 Remove base/move.h; use std::move() instead of Pass()
8a2363f486e3 Move basictypes.h to macros.h
R=avi@chromium.org
Review URL: https://codereview.chromium.org/1566713002 .
This more-natural spelling doesn’t require Crashpad developers to have
to remember anything special when writing code in Crashpad. It’s easier
to grep for and it’s easier to remove the “compat” part when pre-C++11
libraries are no longer relevant.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1513573005 .
Fixes two incorrect usages of ssize_t/off_t being implicitly converted
to bool. As such, I think it's worth the cost of the additional !! on
BOOL returning Win32 functions.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1408123006 .
This makes the basics of !peb work in windbg, however, pointed-to things
are not yet retrieved. For full functionality, a variety of pointers in
the PEB also needs to be walked and captured.
e.g.
Previously:
0:000> .ecxr
eax=00000007 ebx=7e383000 ecx=c3f9a943 edx=00000000 esi=006d62d0 edi=003c9280
eip=00384828 esp=005bf634 ebp=005bf638 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
00384828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7e383000
error 1 InitTypeRead( nt!_PEB at 7e383000)...
Now:
0:000> .ecxr
eax=00000007 ebx=7f958000 ecx=02102f4d edx=00000000 esi=00e162d0 edi=01389280
eip=01344828 esp=00c2fb64 ebp=00c2fb68 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
01344828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7f958000
InheritedAddressSpace: No
ReadImageFileExecOptions: No
BeingDebugged: No
ImageBaseAddress: 01340000
Ldr 77ec8b40
*** unable to read Ldr table at 77ec8b40
SubSystemData: 00000000
ProcessHeap: 00e10000
ProcessParameters: 00e114e0
CurrentDirectory: '< Name not readable >'
WindowTitle: '< Name not readable >'
ImageFile: '< Name not readable >'
CommandLine: '< Name not readable >'
DllPath: '< Name not readable >'
Environment: 00000000
Unable to read Environment string.
R=mark@chromium.org
BUG=crashpad:46
Review URL: https://codereview.chromium.org/1364053002 .
After 9e79ea1da719, it no longer makes sense for crashpad_util_test_lib
to “hide” in util/util_test.gyp. All of util/test is moved to its own
top-level directory, test, which all other test code is allowed to
depend on. test, too, is allowed to depend on all other non-test code.
In a future change, when crashpad_util_test_lib gains a dependency on
crashpad_client, it won’t look so weird for something in util (even
though it’s in util/test) to depend on something in client, because the
thing that needs to depend on client will live in test, not util.
BUG=crashpad:33
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1051533002
In a future change, crashpad_util_test_lib will gain a dependency on
crashpad_client. This would violate GYP’s prohibition on circular
dependencies between .gyp files, although there would be no circular
relationship between the targets themselves. To overcome this problem,
all test-related targets are moved into their own first-class .gyp
files.
BUG=crashpad:33
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1045173004
Add MapInsertOrReplace<>() to insert a key-value pair into a map if the
key is not already present, or replace the existing value for key if the
key is present. The original value can optionally be returned to the
caller in this case.
Map insertions now use either MapInsertOrReplace<>() or
std::map<>::insert() directly.
Use MapInsertOrReplace<>() when the map should be updated to contain a
mapping from a key to a value regardless of whether the key is already
present.
Use std::map<>::insert() to insert a mapping from a key to a value
without replacing any existing mapping from a key, if present. If it is
important to know whether an existing mapping from a key was present,
use the returned std::pair<>.second. If it is important to know the
existing value, use the returned std::pair<>.first->second.
This change has a slight positive impact on performance.
TEST=crashpad_util_test MapInsert.MapInsertOrReplace and others
BUG=
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1044273002
Now that Chrome’s about:crashes displays the crash report UUID, I wanted
to add it to the minidump. In the future, we may be able to index these
on the server. This will also help identify dumps that correspond to the
same event once we’re equipped to convert between different formats.
Ideally, this new field is populated with the same UUID used locally in
the crash report database. To make this work,
CrashReportDatabase::NewReport must carry the UUID. This was actually
part of CrashReportDatabaseWin’s private extension to NewReport, so that
extension subclass can now be cleaned up.
TEST=crashpad_minidump_test MinidumpCrashpadInfoWriter.*,
crashpad_client_test CrashReportDatabaseTest.NewCrashReport
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1000263003
This regressed in 359bdd86225c when a non-POD UUID data member was added
to MinidumpCrashpadInfo, which made MinidumpCrashpadInfo non-POD. This
problem seems to have affected MinidumpModuleCodeViewRecordPDB70 since
it was added, but it is not likely to have caused any problems there
because that structure never appears without having all of its members
populated. By comparison, MinidumpCrashpadInfo may be sparsely
populated.
This caused 4 of the 5 MinidumpCrashpadInfoWriter tests to fail on
Windows.
TEST=crashpad_minidump_test MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1001683002
The client ID is added to a new field, MinidumpCrashpadInfo::client_id,
in each minidump file that is written. The ProcessSnapshot::ClientID()
gives access to value at the snapshot level. In the upload thread,
client IDs are retrieved from minidump files and used to populate the
“guid” HTTP form parameter.
The Breakpad client supplies these values at upload without hyphens and
with all capital letters. Currently, the Crashpad client uses hyphens
and lowercase letters when communicating with a Breakpad server.
TEST=crashpad_minidump_test MinidumpCrashpadInfoWriter.*,
crashpad_snapshot_test ProcessSnapshotMinidump.*,
run_with_crashpad --handler crashpad_handler \
-a --database=/tmp/crashpad_db \
-a --url=https://clients2.google.com/cr/staging_report \
-a --annotation=prod=crashpad \
-a --annotation=ver=0.7.0 \
crashy_program
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/998033002
Likewise for EXPECT_DEATH_CHECK() and EXPECT_DEATH().
In the in-Chromium build configured for official builds in Release mode,
CHECK() throws away its condition string and stream parameters without
ever printing them, although it still evaluates the condition and
triggers death appropriately. {ASSERT,EXPECT}_DEATH(statement, regex)
will not work correctly for any regex that attempts to match what
CHECK() prints. In these build configurations,
{ASSERT,EXPECT}_DEATH_CHECK() use a match-all regex (""). In other build
configurations, they transparently wrap {ASSERT,EXPECT}_DEATH().
BUG=crashpad:12
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/992693003
