This updates build/gyp_crashpad_android.py to define the
android_api_level GYP variable whenver unified headers are in use.
Previously, it was only set when compiling with GCC and using unified
headers. This pairs with https://crrev.com/c/804574 to allow proper
detection of when _FILE_OFFSET_BITS=64 would be inappropriate.
Since there’s no longer any possibility of using a 64-bit off_t with API
< 21, this also drops the compatibility wrapper for mmap() that allowed
this configuration to work. Too bad, I liked this, but it’s pointless to
carry now.
The development documentation is also updated to refer to NDK r16.
mini_chromium is updated to 88e056258a01450b07414642fa5fb98493c1f6ce.
f609089390cd fuchsia: Add ZX_LOG, et al. to mini_chromium
0a8c5de30c67 fuchsia: Fix RandBytes() ZX_CHECK message string
88e056258a01 android: Don’t use _FILE_OFFSET_BITS=64 until API 21
Change-Id: I932116e0c01bcddd5719f9091a070d504eae600f
Reviewed-on: https://chromium-review.googlesource.com/804555
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
third_party/gtest/BUILD.gn mostly written by rsesek.
Also includes DEPS roll of mini_chromium for Wexit_time_destructors config.
$ git log --oneline dd0c3e96..fa146c12
fa146c1 (HEAD, origin/master, origin/HEAD) gn: Extract Wexit-time-destructors into separate config
95bfddb fuchsia: Fix base::RandBytes() after 5a1c5f82ce75
b79608a fuchsia: Use llvm-ar from the Fuchsia clang package
c34725b fuchsia: Look for the toolchain and SDK in per-build-host directories
e8e1ee4 fuchsia: Don't assume that kernel will provide all requested rand bytes
5a1c5f8 fuchsia: Implement RandBytes()
df359ca fuchsia: Enable -fPIC
bd50c95 Restore accidentally changed license
a70db15 Improvements to GN build config
7de4d23 fuchsia: Fix compile of base/logging.cc
25a8b57 Add link GN rules to non-win build, set c++14 in CC flags.
7d15806 fuchsia: The very basics of compiling mini_chromium/base with GN
Bug: crashpad:79, crashpad:196
Change-Id: I3e741f185b028a96705eefc1f993037830d97448
Reviewed-on: https://chromium-review.googlesource.com/797414
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
- Some missed set_sources_assignment_filters if'ing
- Exclude posix/symbolic_constants_posix.(h|cc) as they don't compile and
won't be necessary
- Exclude a handful of other posix files that don't make sense on Fuchsia.
Bug: crashpad:196
Change-Id: I9ec985f00488267dc104164445c6cc5bca36a1fc
Reviewed-on: https://chromium-review.googlesource.com/798220
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
When I redid the Crashpad GN build a few weeks ago
(https://chromium-review.googlesource.com/c/chromium/src/+/751403), I
tried to order things according to the GN style guide
(https://chromium.googlesource.com/chromium/src/tools/gn/+/HEAD/docs/style_guide.md).
As for conditionals, I tried to stick to doing a set of conditionals
after “sources” for just “sources”, and then another one at the bottom
for everything else.
It turns out that this was a good idea because it’s an error to say
“deps += [something]” inside a conditional until you’ve already said
“deps = [something_else]” first. (Maybe that’s why I did it.)
9465fc72ad90 regressed this.
2bb56fafe3bd also left behind a couple of straggler paths that were
absolute to Chromium’s root but should have been made relative.
This also fixes a comment (about something that won’t yet work outside
of Chromium anyway, but still…)
Bug: crashpad:79
Change-Id: I8a6f84bfad368cbcdae4fbff11f1d00e2af14b93
Reviewed-on: https://chromium-review.googlesource.com/798172
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This avoids relying on set_sources_assignment_filter, and so gets closer
to a correct set of files to build on Fuchsia.
Bug: crashpad:79, crashpad:196
Change-Id: Ib7daa5137935113c6645b72eb1dedd943a9db96e
Reviewed-on: https://chromium-review.googlesource.com/797672
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Change-Id: I28edc00549d51576ab553f401235aa1d9f669232
Reviewed-on: https://chromium-review.googlesource.com/797335
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
- Correctly sets target_cpu and current_cpu so correct toolchain
can be used on Fuchsia.
- Introduces GN argument "crashpad_in_chromium" which defaults to
false. Used to set CRASHPAD_IN_CHROMIUM define, determine which
zlib path to use, and how to package the test targets into
binaries (one big one in Chromium, separate in Crashpad).
Bug: crashpad:79, crashpad:196
Change-Id: If6560dc064308ed6f8bf7c75cf74f684a3522e8b
Reviewed-on: https://chromium-review.googlesource.com/797354
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
It’s better to be prepared for the future than…to not be.
This is mostly the result of running 2to3 on all .py files, with some
small shims to maintain compatibility with Python 2.
http_transport_test_server.py was slightly more involved, requiring many
objects to change from “str” to “bytes”.
The #! lines and invokers still haven’t changed, so these scripts will
still normally be interpreted by Python 2.
Change-Id: Idda3c5650f967401a5942c4d8abee86151642a2e
Reviewed-on: https://chromium-review.googlesource.com/797434
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
I like to share a single Crashpad checkout between my non-virtual
machine and some virtual machines. Downloaded toolchains, which vary by
build host configuration, must go in paths named for the build host.
(Chromium doesn’t do this, and it bugs me.)
Rather than downloading the Fuchsia toolchain to
third_party/fuchsia/clang, this puts it in
third_party/fuchsia/clang/{mac,linux}-amd64.
The Fuchsia SDK is only published on cipd for linux-amd64, but the
sysroot that it contains ought to be perfectly functional on any
suitably-equipped build host, so this also checks out that package
unconditionally.
Bug: crashpad:196
Change-Id: Iabd4f2dd1e2c06a3f7208b5c40432619983919ea
Reviewed-on: https://chromium-review.googlesource.com/794537
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
- Adds a .gn and a build/BUILDCONFIG.gn that uses mini_chromium's
build/BUILD.gn.
- Adds some stub BUILD.gn files in locations where Chromium expects them
(in //build, //testing, //third_party) containing empty targets/configs.
These are no-ops in standalone builds, but add functionality when
building in Chromium. This is in preference to having a global bool
that conditionally does Chromium-y things in the Crashpad build files.
These stub files are all contained in a secondary source root in
build/chromium_compatibility, referred to by //.gn.
- Adds //base/BUILD.gn which forwards to mini_chromium/base. This is
only used when building standalone so that both Chromium and Crashpad
can refer to it as "//base".
- Changes references to other Crashpad targets to be relatively
specified so that they work when the root of the project is //, and also
when it's //third_party/crashpad/crashpad as it is in Chromium.
- Moves any error-causing Mac/Win-specific files into explicit if (is_mac)
or if (is_win) blocks as part of removing the dependency on
set_sources_assignment_filter().
As yet unresolved:
- CRASHPAD_IN_CHROMIUM needs to be removed when standalone; to be tackled
in a follow up.
- Not sure what to do with zlib yet, the build file currently assumes
"in Chromium" too, and similarly having Crashpad //third_party/zlib:zlib
pointing at itself doesn't work.
Bug: crashpad:79
Change-Id: I6a7dda214e4b3b14a60c1ed285267ab97432a1a8
Reviewed-on: https://chromium-review.googlesource.com/777410
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
In Chromium, the AnnotationList is registered in the main executable
module. However, when using the component build, the individual shared
libraries do not explicitly initialize the CrashpadInfo nor
AnnotationList. This causes annotations to NULL-dereference the
uninitialized AnnotationList when using the component build.
By using the Register method instead, the AnnotationList will be lazily
created. In Chromium's static/release build, the AnnotationList will
still be initialized deterministically during startup.
Bug: crashpad:192
Change-Id: I8599b52630f4d7608e5028b14264a8eed49a9176
Reviewed-on: https://chromium-review.googlesource.com/793981
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
There's no particular UUID generator on Fuchsia, so use the RandBytes()
version. (That won't work either yet, but will once RandBytes() is
implemented.)
Bug: crashpad:196
Change-Id: Id740bbfc80e170d7ab19995ac88db5eed474c119
Reviewed-on: https://chromium-review.googlesource.com/786822
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These use CIPD (from depot_tools) to download packages created by the
Fuchsia team. The .ensure file is passed to `cipd` which currently
include specificiations for the Fuchsia team's build of clang (which,
because it's close to HEAD includes support for targeting Fuchsia), as
well as the Fuchsia SDK.
Both packages are specified as "latest" rather than pinning to a
specific revision. At this early point in the process we don't have any
good reason to pin, but that can be accomplished later by replacing that
with a specific package's SHA1.
Due to the (relatively new) 'condition': 'checkout_fuchsia', this DEPS
step will only be run when .gclient includes 'fuchsia' in the target_os
block at the top_level, e.g.
$ cat .gclient
solutions = [
{ ... },
]
target_os = ['fuchsia']
Bug: crashpad:196, crashpad:209
Change-Id: Id6d444a1c4450ffde8ee6665ff9720ce454c5cdf
Reviewed-on: https://chromium-review.googlesource.com/786092
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Bug: crashpad:196
Change-Id: I4f01c4f04c94a745b4c30bc41f66d2ae010e883a
Reviewed-on: https://chromium-review.googlesource.com/786817
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
I have no idea if this will work as not much is building yet, but it
seems plausible for the time being.
Bug: crashpad:196
Change-Id: Ie3a358512a968e9e777ed03c0bffc5e273a0f12e
Reviewed-on: https://chromium-review.googlesource.com/786777
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
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>
These are large, not pinned (floating at HEAD), and we’re not currently
using them.
Change-Id: I550f832aeb42db8404fdb764f78e83136a2a7ef6
Reviewed-on: https://chromium-review.googlesource.com/779668
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
The exception swallower server’s design and interface are both
considerably simpler when the server runs in a thread in the parent test
process, as opposed to a separate process. The only caveat is that this
results in calls to fork() while threaded. Uses of gtest
{ASSERT,EXPECT}_DEATH with the default “fast” gtest death test style
result in this warning:
[WARNING] ../../third_party/gtest/gtest/googletest/src/gtest-death-test.cc:836:: Death tests use fork(), which is unsafe particularly in a threaded context. For this test, Google Test detected 2 threads.
Bug: crashpad:33
Change-Id: Ib8f418064ea4ab942859c3393cb15cf71365614d
Reviewed-on: https://chromium-review.googlesource.com/779481
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@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>
These were missed with the mig.py change in
6dd2be7c44a9c8bbea5df918e7ebe46d76da97df.
Change-Id: I7ad066cd9425cab26e56a8b3dfb90f5f54a6648d
Reviewed-on: https://chromium-review.googlesource.com/774999
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Rather than providing these stubs to make the linker happy, use the
mig.py script to modify the _Xserver_routine functions to not even call
server_routine.
Change-Id: I5a2f5cd228462e38dddbf899d0ad8033a6f817bd
Reviewed-on: https://chromium-review.googlesource.com/773359
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The handler will now be less strict about checking CrashpadInfo struct
sizes. Assuming the signature and version fields match:
- If the handler sees a struct smaller than it’s expecting, the module
was likely built with an earlier version of the client library, and
it’s safe to treat the unknown fields as though they were zero or
other suitable default values.
- If the handler sees a struct larger than it’s expecting, the module
was likely built with a later version of the client library. In that
case, actions desired by the client will not be performed, but this
is not otherwise an error condition.
The CrashpadInfo struct must always be at least large enough to contain
at least the size field. The signature and version fields are always
checked.
The section size must be at least as large as the size carried within
the struct. To account for possible section padding, strict equality is
not required.
Bug: chromium:784427
Test: crashpad_snapshot_test CrashpadInfoSizes_ClientOptions/*.*
Change-Id: Ibb0690ca6ed5e7619d1278a68ba7e893d55f19fb
Reviewed-on: https://chromium-review.googlesource.com/767709
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
glibc’s own <sys/ptrace.h> should provide this but doesn’t. See
https://sourceware.org/bugzilla/show_bug.cgi?id=22433.
The copy in compat provided it when targeting x86-64 and using glibc.
util/linux/ptracer.cc uses it when targeting both 32-bit x86 and x86-64,
so the compat definition must be made to apply to 32-bit x86 too.
This also provides a #define using the same name as the constant, which
is what glibc’s <sys/ptrace.h> does for other constants.
Bug: crashpad:30
Change-Id: I5a0734a236d1c25398fb69e66f58dfe118658b68
Reviewed-on: https://chromium-review.googlesource.com/765257
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When this test examines a module that doesn’t have a CodeView PDB link,
it will fail. Such a link may be missing when linking with Lexan
ld-link.exe without /DEBUG. The test had been examining the executable
as its module. Since it’s easier to provide a single small module linked
with /DEBUG than it is to require that the test executable always be
linked with /DEBUG, the test is revised to always load a module and
operate on it. The module used is the existing
crashpad_snapshot_test_image_reader_module.dll. It was chosen because
it’s also used by PEImageReader.DebugDirectory, which also requires a
CodeView PDB link.
It’s the build system’s responsibility to ensure that
crashpad_snapshot_test_image_reader_module.dll is linked appropriately.
Crashpad’s own GYP-based build always links with /DEBUG. Chrome’s
GN-based Crashpad build will require additional attention at
symbol_level = 0.
Bug: chromium:782781
Change-Id: I0dda8cd13278b82842263e76bcc46362bd3998df
Reviewed-on: https://chromium-review.googlesource.com/761501
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
crashpad_snapshot_test PEImageReader.DebugDirectory was hanging when
crashpad_snapshot_test_image_reader.exe did not have a CodeView PDB
link. This occurred when linked by Lexan ld-link.exe without /DEBUG.
Bug: chromium:782781
Change-Id: I8fbc4d8decf6ac5e19f7ffeb230fd15d7c40fd51
Reviewed-on: https://chromium-review.googlesource.com/761320
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
Traditional NDK headers provide the nanoseconds field of modification
time as st_mtime_nsec, rather than contained in a timespec st_mtim.
Unified headers do provide the timespec st_mtim.
Bug: crashpad:206
Change-Id: I701ac2d5e357a13855a2a674f1355f2ea125ee4e
Reviewed-on: https://chromium-review.googlesource.com/760618
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
FileModificationTime gets the last write time for files, directories,
or symbolic links. Symbolic links may point to files, directories, or
be dangling.
Bug: crashpad:206
Change-Id: Ic83b5a7d318502ad5db5c01731d06c8624925e15
Reviewed-on: https://chromium-review.googlesource.com/744298
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Change-Id: Ibecedd195224ea53ff36f376897a6ff3c4e773d2
Reviewed-on: https://chromium-review.googlesource.com/757085
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This was previously proposed at
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/339103/2/util/win/pe_image_reader_test.cc#84.
It didn’t land because the change was abandoned for other reasons, but
the fix was valid. nsi.dll is not VFT_APP or VFT_DLL, and if it’s
loaded, crashpad_snapshot_test PEImageReader.VSFixedFileInfo_AllModules
fails.
Although I can’t reproduce nsi.dll being loaded spontaneously in local
testing or on trybots, it occurred in the monolithic crashpad_tests at
https://build.chromium.org/p/chromium.win/builders/Win7%20Tests%20%28dbg%29%281%29/builds/64492:
[ RUN ] PEImageReader.VSFixedFileInfo_AllModules
../../third_party/crashpad/crashpad/snapshot/win/pe_image_reader_test.cc(90): error: Value of: observed.dwFileType == VFT_APP || observed.dwFileType == VFT_DLL
Actual: false
Expected: true
Google Test trace:
../../third_party/crashpad/crashpad/snapshot/win/pe_image_reader_test.cc(164): C:\Windows\syswow64\NSI.dll
[ FAILED ] PEImageReader.VSFixedFileInfo_AllModules (11 ms)
I can also reproduce locally by calling LoadLibrary(L"nsi.dll").
Bug: chromium:779790, chromium:782011
Test: crashpad_snapshot_test PEImageReader.VSFixedFileInfo_AllModules
Change-Id: I361c7d6521645913277a441ce38779aaa4a182c2
Reviewed-on: https://chromium-review.googlesource.com/757077
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@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 CL pulls together similar time conversion functions and adds
conversions between `FILETIME`s and `timespec`s.
Bug: crashpad:206
Change-Id: I1d9b1560884ffde2364af0092114f82e1534ad1c
Reviewed-on: https://chromium-review.googlesource.com/752574
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
7f523b111c8c win: Don’t define c16*() functions in
base/strings/string16.{cc,h}
dd0c3e9680ae Use ICU 60.1 as the basis for base/third_party/icu
Change-Id: I21b921c36a3ee1f989fa9786f60d980724577f64
Reviewed-on: https://chromium-review.googlesource.com/755215
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This wires up the annotation objects system of the client to the
snapshot production and minidump writing facilities.
Bug: crashpad:192
Change-Id: If7bb7625b140d71a15b84729372cbd0fd4bc63ef
Reviewed-on: https://chromium-review.googlesource.com/749870
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
This extracts string annotation objects from the minidumps and includes
them as form POST key-value pairs.
This change also starts building a crashpad_handler_test binary on Mac.
Bug: crashpad:192
Change-Id: I68cbf6fda6f1e57c1e621d5e3de8717cfaea65bf
Reviewed-on: https://chromium-review.googlesource.com/749793
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This test code appeared in 9609b7471676, and was missed by the similar
warning cleanup of a51e912004a6, which was developed in parallel.
Bug: crashpad:192, chromium:779790
Change-Id: I4ed88ed025e4be4410c98ceaca395218f00007be
Reviewed-on: https://chromium-review.googlesource.com/750024
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This will be used to include the annotations as form-post data when
uploading reports.
Bug: crashpad:192
Change-Id: I85ba9afd3cae7c96c0f8fe4f31a2460c97ed42d3
Reviewed-on: https://chromium-review.googlesource.com/747514
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: 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 is causing crashpad_handler_test to fail in Debug on Windows.
Bug: crashpad:192
Change-Id: Icf3ff387050ee2becf471f4e7c3a75394b1dd436
Reviewed-on: https://chromium-review.googlesource.com/749792
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>
81eced5192d9 added a a dependency on
crashpad_snapshot_test_simple_annotations to crashpad_snapshot_test, but
9609b7471676 renamed this target to crashpad_snapshot_test_annotations.
I should have rebased onto HEAD, rebuilt, and retested before landing.
Bad developer! No candy. 🎃
Change-Id: I8fcd1020d8bd4ee163afa555ae6e815325485024
Reviewed-on: https://chromium-review.googlesource.com/748814
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Instead of individual per-directory test executables like
crashpad_util_test, all Crashpad tests in Chromium will be run from a
single crashpad_tests executable.
Test: crashpad_util_test Paths.Executable, ProcessInfo.Self; crashpad_snapshot_test PEImageReader.DebugDirectory
Bug: chromium:779790
Change-Id: If95272fd641734fbdb8e231fbcdc4e7ccb2cb822
Reviewed-on: https://chromium-review.googlesource.com/749303
Reviewed-by: Scott Graham <scottmg@chromium.org>
The design for running all Crashpad unit tests on Chromium’s try- and
buildbots involves pulling all tests into a single monolithic
crashpad_tests executable. Many Crashpad tests base the name of their
child executables or modules on the name of the main test executable.
Since the main test executable will have a different name in the
in-Chromium build, knowledge of the test executable name (referred to as
“module” here) needs to be added to the tests themselves.
This introduces TestPaths::BuildArtifact(), which allows the module name
to be specified. For Crashpad’s standalone build, the module name is
verified against the main test executable’s name.
TestPaths::BuildArtifact() can also locate paths in the alternate 32-bit
output directory for 64-bit Windows tests, taking on the responsibility
for what the new (5e9ed4cb9f69) TestPaths::Output32BitDirectory(), now
obsolete, did.
Bug: chromium:779790
Change-Id: I64c4a2190b6319e487c999812a7cfc512a75a700
Reviewed-on: https://chromium-review.googlesource.com/747536
Reviewed-by: Scott Graham <scottmg@chromium.org>
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>
Crashpad’s own build always uses wWinMain(), the default entry point for
/subsystem:windows, producing crashpad_handler.exe. crashpad_handler.com
is a /subsystem:console version produced by running editbin on a copy of
crashpad_handler.exe. This leaves the entry point intact, so both copies
use wWinMain(). crashpad_handler.com does not use wmain() as
traditionally used by /subsystem:console programs.
For the in-Chromium build’s tests, it is conveient to produce the
/subsystem:console version, crashpad_handler.com, directly as linker
output, as opposed to using editbin to transform a /subsystem:windows
version. This /subsystem:console version uses the normal wmain() entry
point.
By providing both wWinMain() and wmain(), both build types can be
accommodated.
Bug: chromium:779790
Change-Id: Ieb784db0cc245c6e4c12fb1dd83b8b95e159bdec
Reviewed-on: https://chromium-review.googlesource.com/746161
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
Two dependency targets were missing from crashpad_snapshot_test.
Change-Id: I9efba73639e529313d4aa49df5e68bb5117cf95a
Reviewed-on: https://chromium-review.googlesource.com/746121
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
testing::InitGoogleMock() and testing::InitGoogleTest() modify argc and
argv, removing --gtest_* arguments that are processed. When building as
a part of Chromium, this prevents these arguments from being visible to
Chromium’s base::LaunchUnitTests() test runner.
Only call these initialization functions when using gtest’s native
RUN_ALL_TESTS() test runner.
Change-Id: I8242e1047f90d1cd923518a5cb9bd2527201ad25
Reviewed-on: https://chromium-review.googlesource.com/746082
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
These utilities will be useful for database tests.
Bug: crashpad:206
Change-Id: Iae0d831934ea7f020f167dbbcba901a72472937b
Reviewed-on: https://chromium-review.googlesource.com/747885
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Nothing currently directs the handler to read these Annotation objects
from the target process, so they will not be read by Crashpad nor appear
in the minidump.
Bug: crashpad:192
Change-Id: I1eb1e9f42282c07e37d335631f0cc6083ef28a89
Reviewed-on: https://chromium-review.googlesource.com/726501
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Nothing currently directs the handler to read these Annotation objects
from the target process, so they will not be read by Crashpad nor appear
in the minidump.
Bug: crashpad:192
Change-Id: I8ebabb4f5c77c5620b0d8e5036c3185eecfa4646
Reviewed-on: https://chromium-review.googlesource.com/717236
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@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>
The AnnotationSnapshot is the handler-side of the Annotation object,
which will store the annotation data when read by a ProcessReader.
Bug: crashpad:192
Change-Id: Ic65c95022c452522678c1070c27c429dd631fb64
Reviewed-on: https://chromium-review.googlesource.com/717197
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
../../third_party/crashpad/crashpad/util/file/filesystem_test_util.cc(79,27): error: comparison of integers of different signs: 'DWORD' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (symbolic_link_flags == -1) {
~~~~~~~~~~~~~~~~~~~ ^ ~~
In file included from ../../third_party/crashpad/crashpad/util/file/filesystem_test_util.cc:23:
../../third_party/googletest/src/googletest/include\gtest/gtest.h(1392,11): error: comparison of integers of different signs: 'const unsigned long' and 'const long' [-Werror,-Wsign-compare]
if (lhs == rhs) {
~~~ ^ ~~~
../../third_party/googletest/src/googletest/include\gtest/gtest.h(1421,12): note: in instantiation of function template specialization 'testing::internal::CmpHelperEQ<unsigned long, long>' requested here
return CmpHelperEQ(lhs_expression, rhs_expression, lhs, rhs);
^
../../third_party/crashpad/crashpad/util/file/filesystem_test_util.cc(73,5): note: in instantiation of function template specialization 'testing::internal::EqHelper<false>::Compare<unsigned long, long>' requested here
EXPECT_EQ(error, ERROR_PRIVILEGE_NOT_HELD)
^
../../third_party/googletest/src/googletest/include\gtest/gtest.h(1924,63): note: expanded from macro 'EXPECT_EQ'
EqHelper<GTEST_IS_NULL_LITERAL_(val1)>::Compare, \
^
2 errors generated.
and
../../third_party/crashpad/crashpad/util/file/filesystem_test_util.cc(111,5): note: in instantiation of function template specialization 'testing::internal::EqHelper<false>::Compare<unsigned long, long>' requested here
EXPECT_EQ(GetLastError(), ERROR_FILE_NOT_FOUND)
^
Change-Id: I55b33b39c271d765376ff9c416e737d0608eb781
Reviewed-on: https://chromium-review.googlesource.com/742561
Reviewed-by: Scott Graham <scottmg@chromium.org>
As of
00a0654929,
crashpad_util_test is able to run in Chromium. It uses Chromium’s own
base::TestLauncher rather than gtest’s RUN_ALL_TESTS() for proper
integration with Swarming.
Launching WinMultiprocess test children out of the same test executable
via WinChildProcess is not compatible with Chromium’s parallel, shardy,
Swarmy test launcher. When running these children, the standard gtest
RUN_ALL_TESTS() launcher will now be used, even in Chromium.
Two tests disabled in Chromium are now enabled:
ExceptionHandlerServerTest.MultipleConnections and
ScopedProcessSuspend.ScopedProcessSuspend.
As part of this work, I discovered that disabled tests chosen to run via
--gtest_also_run_disabled_tests did not actually work for
WinMultiprocess-based tests, because gtest’s test launcher would refuse
to run the child side of the test, believing it was disabled. This is
fixed by always supplying --gtest_also_run_disabled_tests to
WinChildProcess children, on the basis that if the parent is managing to
run and it’s disabled, disabled tests must actually be enabled.
Bug: crashpad:205
Change-Id: Ied22f16b9329ee13b6b07fd29de704f6fe2a058e
Reviewed-on: https://chromium-review.googlesource.com/742462
Reviewed-by: Scott Graham <scottmg@chromium.org>
This upstreams part of
00a0654929.
The gmock_main and gtest_main test launchers detect via a
CRASHPAD_IN_CHROMIUM macro that they are building as part of Chromium,
and use Chromium’s custom test launcher rather than gtest’s
RUN_ALL_TESTS(). This enables parallelism, sharding, and integration
with Swarming.
WinMultiprocess-based tests are not compatible with this test launcher
or with the Swarming test design, and must be disabled when
CRASHPAD_IN_CHROMIUM is set. This is covered by
https://crashpad.chromium.org/bug/205.
CRASHPAD_IN_CHROMIUM is never defined during Crashpad’s own standalone
build, it’s only defined when building in Chromium.
Change-Id: I969c5d376f86ab4b3f4cc85c97d4452b53b35063
Reviewed-on: https://chromium-review.googlesource.com/740988
Reviewed-by: Nico Weber <thakis@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
As mentioned at
https://chromium-review.googlesource.com/c/chromium/src/+/735820#message-e8b199498d8b850f2612c46648069d819dd47517,
the typical Windows behavior for symbolic links requires administrative
privileges.
Symbolic links are available to non-administrators in Windows 10.0.15063
and later (1703, Creators Update), provided that developer mode has been
enabled and SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE is passed to
CreateSymbolicLink(). See
https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/.
This adds SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE to uses of
CreateSymbolicLink(), and creates test::CanCreateSymbolicLinks() to
determine whether symbolic link creation is possible. Tests that
exercise symbolic links are adapted to gate all symbolic link operations
on this test.
Test: crashpad_util_test DirectoryReader.*:Filesystem.*
Change-Id: I8250cadd974ffcc7abe32701a0d5bc487061baf0
Bug: crashpad:
Reviewed-on: https://chromium-review.googlesource.com/739472
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
As the crashing function runs inside GoogleTests SEH handler,
I think it, or something in the OS may be interfering with the
exception dispatch somehow. In any case, if this flakes, we have
no one to blame but ourselves.
Bug: crashpad:773569
Change-Id: I2230d02735be4a71b688e1acc94d0ae6f082d9bd
Reviewed-on: https://chromium-review.googlesource.com/739464
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Rather than having the 64-bit build assume that it lives in
out\{Debug,Release}_x64 and that it can find 32-bit build output in
out\{Debug,Release}, require the location of 32-bit build output to be
provided explicitly via the CRASHPAD_TEST_32_BIT_OUTPUT environment
variable. If this variable is not set, 64-bit tests that require 32-bit
test build output will dynamically disable themselves at runtime.
In order for this to work, a new DISABLED_TEST() macro is added to
support dynamically disabled tests. gtest does not have its own
first-class support for this
(https://groups.google.com/d/topic/googletestframework/Nwh3u7YFuN4,
https://github.com/google/googletest/issues/490) so this local solution
is used instead.
For tests via Crashpad’s own build\run_tests.py, which is how Crashpad’s
own buildbots and trybots invoke tests, CRASHPAD_TEST_32_BIT_OUTPUT is
set to a locaton compatible with the paths expected for the GYP-based
build. No test coverage is lost on Crashpad’s own buildbots and trybots.
For Crashpad tests in Chromium’s buildbots and trybots, this environment
variable will not be set, causing these tests to be dynamically
disabled.
Bug: crashpad:203, chromium:743139, chromium:777924
Change-Id: I3c0de2bf4f835e13ed5a4adda5760d6fed508126
Reviewed-on: https://chromium-review.googlesource.com/739795
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This introduces the Annotation object, used to declare typed
annotations, and the AnnotationList object, used to reference these. The
AnnotationList is referenced by the CrashpadInfo structure. Currently
nothing reads these.
The AnnotationList implements a lock-free linked list, into which
Annotation objects are added exactly once, when they are first set.
Clearing an Annotation merely marks it internally as such, rather than
removing it from the list.
Bug: crashpad:192
Change-Id: I72414b1f83d624c4ae323e09ecea8cfb69a68c5e
Reviewed-on: https://chromium-review.googlesource.com/547135
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
There’s no reason for ProcessReader to own its ProcessMemoryLinux via
std::unique_ptr<>.
This was discovered in a trunk Clang build, during which a
-Wdelete-non-virtual-dtor warning was produced (since Clang r312167).
The warning is not produced by earlier Clang versions or by GCC because
the “delete” happens in a system header, <memory>, when performed by
std::unique_ptr<>. Although ownership via std::unique_ptr<> is no longer
used, ProcessMemoryLinux is marked “final” because it ought to be.
In file included from ../../snapshot/linux/process_reader.cc:15:
In file included from ../../snapshot/linux/process_reader.h:21:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../include/c++/7.2.0/memory:80:
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../include/c++/7.2.0/bits/unique_ptr.h:78:2: error: delete called on non-final 'crashpad::ProcessMemoryLinux' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non-virtual-dtor]
delete __ptr;
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../include/c++/7.2.0/bits/unique_ptr.h:268:4: note: in instantiation of member function 'std::default_delete<crashpad::ProcessMemoryLinux>::operator()' requested here
get_deleter()(__ptr);
^
../../snapshot/linux/process_reader.cc:169:16: note: in instantiation of member function 'std::unique_ptr<crashpad::ProcessMemoryLinux, std::default_delete<crashpad::ProcessMemoryLinux> >::~unique_ptr' requested here
ProcessReader::ProcessReader()
^
1 error generated.
Change-Id: Ibe9671db429262aca12bbfdf457c8f72cad2f358
Reviewed-on: https://chromium-review.googlesource.com/738530
Reviewed-by: Dave Bort <dbort@google.com>
Commit-Queue: Mark Mentovai <mark@chromium.org>
P0012R1, accepted into C++17, makes a function’s “noexcept” (or
“throw()”) specification part of its signature. GCC 7.2 provides a
warning, -Wnoexcept-type, that is triggered when a function pointer type
with an exception specification is used in pre-C++17 code in such a way
as to pose an ABI incompatibility with C++17 code.
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/C_002b_002b-Dialect-Options.html#index-Wnoexcept-type
Warnings are of the form:
In file included from ../../util/misc/from_pointer_cast_test.cc:15:0:
../../util/misc/from_pointer_cast.h:64:1: error: mangled name for ‘typename std::enable_if<(std::is_pointer<From>::value && std::is_pointer<_Tp>::value), To>::type crashpad::FromPointerCast(From) [with To = const volatile void*; From = void* (*)(long unsigned int) throw ()]’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type]
FromPointerCast(From from) {
^~~~~~~~~~~~~~~
../../util/misc/from_pointer_cast.h:64:1: error: mangled name for ‘typename std::enable_if<(std::is_pointer<From>::value && std::is_pointer<_Tp>::value), To>::type crashpad::FromPointerCast(From) [with To = volatile void*; From = void* (*)(long unsigned int) throw ()]’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type]
In Crashpad, this warning is triggered by the two FromPointerCast<>()
variants that accept function pointer “From” arguments. This occurs when
using glibc as the standard C library, since glibc declares its
functions as “throw()”. FromPointerCast<>() is used with pointers to
glibc functions such as malloc() and getpid().
The warning is disabled for the FromPointerCast<>() variants that would
trigger it. The warning is not useful or actionable in this internal
Crashpad code where ABI changes due to language version (including
mangling changes) are not a concern.
Clang 4.0 has the similar -Wc++1z-compat-mangling option (also available
as -Wc++17-compat-mangling and the GCC-compatible -Wnoexcept-type in
Clang 5.0) but it is not triggered by this pattern.
Change-Id: Id293db3954be415f67a55476ca72bfb7d399aa3b
Reviewed-on: https://chromium-review.googlesource.com/738292
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This reverts 55133d332b6c and adds a broken dummy SafeTerminateProcess()
for cross builds instead. It’s similar to 2f4516f93838, which was for
CaptureContext().
This upstreams
af5f31ed61
(slightly modified).
The dummy implementation in the “broken” file affords no protection
against third-party code patching TerminateProcess() badly. The “broken”
file is not used by Crashpad anywhere at all, and is only used by
Crashpad in Chromium during a cross build targeting Windows without the
benefit of Microsoft’s ml.exe assembler. Strictly speaking, this file
does not need to be checked in to the Crashpad repository, but since
Chromium needs it to unblock its not-production-ready cross build for
Windows, it’s being landed here to avoid Chromium’s copy of Crashpad
appearing as modified or “dirty” relative to this upstream copy.
Bug: chromium:762167, chromium:777924
Change-Id: Iba68c0cab142fbe9541ea254a9a856b8263e4c70
Reviewed-on: https://chromium-review.googlesource.com/735078
Reviewed-by: Mark Mentovai <mark@chromium.org>
An #include was missing from 59c5d848e5c5.
Change-Id: Ib0074aefbc8dc231a097c2edd3ef3047f5cff32e
Reviewed-on: https://chromium-review.googlesource.com/734232
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
From edf4dde8ae10: one #include was missing, and another was sorted
incorrectly.
Change-Id: I77825f3909ae81ebf965f8c5527b44c95af29945
Reviewed-on: https://chromium-review.googlesource.com/734229
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
While the kernel formats device major and minor numbers as %02x:%02x,
they are not restricted to 8 bits apiece. Crashpad was requiring that
the hexadecimal representations be exactly two characters, rather than
at least two characters.
The proper way to reconstruct a dev_t from major and minor numbers in
user space is to use makedev() from <sys/sysmacros.h>. MKDEV() from
<linux/kdev_t.h> interfaces with an older (pre-Linux 2.6) format which
actually did use 8-bit major and minor numbers. makedev() places the
major number at bits 8-19, and splits the minor number into two groups
at bits 0-7 and 20-31. This is the correct user space view of device
numbers. (Note that this is distinct from the kernel’s view: the kernel
uses MKDEV() from a distinct internal <linux/kdev_t.h> which places the
minor number at bits 0-19 and the major number at bits 20-31.)
Bionic for 32-bit platforms uses a 32-bit user space dev_t while a
64-bit version is used elsewhere, and a comment in Bionic’s
<sys/types.h> calls this a “historical accident”. However, due to the
kernel’s use of only 32 bits for device numbers, this accident does not
have any ill effect.
Bug: crashpad:30
Test: crashpad_util_test, crashpad_snapshot_test
Change-Id: Ic343454393d7399f598f9eba169a9e5f5630e601
Reviewed-on: https://chromium-review.googlesource.com/733863
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This upstreams
fc1ac734b0
(slightly modified).
This dummy implementation is not used by Crashpad anywhere at all, and
is only used by Crashpad in Chromium during a cross build targeting
Windows without the benefit of Microsoft’s ml.exe/ml64.exe assembler.
Strictly speaking, this file does not need to be checked in to the
Crashpad repository, but since Chromium needs it to unblock its
not-production-ready cross build for Windows, it’s being landed here to
avoid Chromium’s copy of Crashpad appearing as modified or “dirty”
relative to this upstream copy. (Even though this file is really dirty.)
Bug: chromium:762167
Change-Id: Ibfdc316c1f5fe81d4b3a1d86f4032adccac467e5
Reviewed-on: https://chromium-review.googlesource.com/734102
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This is a step towards a database which gives out FileReaders in Report
objects instead of FilePaths.
Change-Id: I59704da65fc5521e5d47019416bf962c215d13bc
Reviewed-on: https://chromium-review.googlesource.com/721978
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This change also adds functions to create directories, remove files and
directories, and check for the existence of files and directories.
Change-Id: I62b78219ae2b277d6976d2d90ec86fcabd0ef073
Reviewed-on: https://chromium-review.googlesource.com/696132
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Only a Linux implementation for now, but similar code for other
OSes can move behind it in the future.
Bug: crashpad:196
Change-Id: I05966db1599a9cac3146d2a3d964e7ad8629d616
Reviewed-on: https://chromium-review.googlesource.com/685408
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Dave Bort <dbort@google.com>
The Crashpad representation of the TEB struct had an incorrect PVOID
reserved of len 397. This should be 402 once we calculate that the other
members occupy 40/80 (32 vs 64) bytes.
Wine has a well documented copy
4df0162caf/include/winternl.h (L309)
that shows the offsets TlsSlots should be at. This patch makes that
change. TlsSlots is now at offset 3600 on 32-bit and offset 5248 on
64-bit.
Change-Id: I4ea4c44b1e49d3ea02d433f386f164703a373dab
Reviewed-on: https://chromium-review.googlesource.com/717040
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Update mini_chromium to 7d6697ceb5cb5ca02fde3813496f48b9b1d76d0c
47ff9691450e Switch the language standard to C++14
7d6697ceb5cb Remove base/memory/ptr_util.h and base::WrapUnique
base::WrapUnique and std::make_unique are similar, but the latter is
standardized and preferred.
Most of the mechanical changes were made with this sed:
for f in $(git grep -l base::WrapUnique | uniq); do
sed -E \
-e 's%base::WrapUnique\(new ([^(]+)\((.*)\)\);%std::make_unique<\1>(\2);%g' \
-e 's%base::WrapUnique\(new ([^(]+)\);%std::make_unique<\1>();%g' \
-e 's%^#include "base/memory/ptr_util.h"$%#include <memory>%' \
-i '' "${f}"
done
Several uses of base::WrapUnique that did not fit on a single line and
were not matched by this sed were adjusted manually. All #include
changes were audited manually, to at least move <memory> into the
correct section. Where <memory> was already #included by a file (or its
corresponding header), the extra #include was removed. Where <memory>
should have been #included by a header, it was added. Other similar
adjustments to other #includes were also made.
Change-Id: Id4e0baad8b3652646bede4c3f30f41fcabfdbd4f
Reviewed-on: https://chromium-review.googlesource.com/714658
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
This corresponds to Windows 10 version 1709 (Fall Creators Update,
“Redstone 3”).
While compiling util/win/nt_internals.cc:
…\crashpad\crashpad\util\win\nt_internals.cc(22): error C2371: 'CLIENT_ID': redefinition; different basic types
c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\winternl.h(83): note: see declaration of 'CLIENT_ID'
The CLIENT_ID structure, which should have been part of the SDK to begin
with, has been added. Provide a compatible definition in <winternl.h>.
Bug: chromium:773476
Change-Id: Iafc77f8cffd06d1194fc909bad587f1ffd1687a2
Reviewed-on: https://chromium-review.googlesource.com/711415
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
A step towards making these files usable by non-Linux systems.
Bug: crashpad:196
Change-Id: Iaa8bfae1c325735c320e502698a61e4851777649
Reviewed-on: https://chromium-review.googlesource.com/685407
Commit-Queue: Dave Bort <dbort@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
A step towards making these files usable by non-Linux systems.
Bug: crashpad:196
Change-Id: I71323b29e46208b3992055722e4622d79409c44c
Reviewed-on: https://chromium-review.googlesource.com/685406
Commit-Queue: Dave Bort <dbort@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
readdir_r() is a thread-safe version of readdir(), although readdir() is
not particularly thread-unsafe with most usage. The dirent* returned by
readdir() can only be invalidated by a subsequent readdir() or
closedir() on the same DIR*. In typical usage, where a returned dirent*
is used exclusively within a loop around readdir() and is not expected
to outlive that loop, there are no lifetime or thread-safety issues with
the use of readdir().
readdir_r() may be harmful in certain situations because its buffer is
not explicitly sized, and attempts to provide a suitably sized buffer
dynamically (which, incidentally, our code did not do) are subject to a
race condition.
https://elliotth.blogspot.com/2012/10/how-not-to-use-readdirr3.htmlhttps://womble.decadent.org.uk/readdir_r-advisory.html
glibc has already deprecated readdir_r(), and all Linux (including
Android) code was already using readdir(). This change eliminates
variant codepaths. It delegates buffer sizing (which we weren’t doing
correctly) to the C library, which also has more options at its disposal
to avoid races in sizing that buffer.
Change-Id: I4fca8948454116360180ad0017f226d06727ef81
Reviewed-on: https://chromium-review.googlesource.com/705756
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Chrome (and therefore mini_chromium) has always built with
_FILE_OFFSET_BITS=64, which is intended to enable a 64-bit off_t even
for 32-bit programs. However, support was never present in Android with
NDK traditional headers.
The new NDK unified headers do recognize _FILE_OFFSET_BITS=64 and enable
a 64-bit off_t, along with corresponding functions and system call
wrappers. However, no mmap() wrapper supporting a 64-bit off_t for
32-bit programs was available prior to API 21 (Android 5.0 “Lollipop”),
so when targeting older API levels, NDK headers do not proivde an mmap()
declaration. This avoids silently truncating 64-bit off_t values to 32
bits. NDK r15b did make such an mmap() wrapper available
(https://android.googlesource.com/platform/bionic/+/785b249df024), and
it did silently truncate, but this was removed for r15c
(https://android.googlesource.com/platform/bionic/+/00fedf587917).
How should this work if _FILE_OFFSET_BITS is set to 64 and recent
unified headers are in use?
The strategy employed here is to provide an mmap() declaration in
compat, with a 64-bit off_t. That mmap() will call to Bionic’s mmap64()
wrapper if available (it’s available since Android 5.0 “Lollipop”). If
unavailable, it implements the same logic that mmap64() does directly,
which predominantly involves calling the __mmap2() system call. Bionic
has always provided wrappers for __mmap2().
Additional reading:
https://android.googlesource.com/platform/bionic/+/0bfcbaf4d069/docs/32-bit-abi.md#is-32_bit-1https://github.com/android-ndk/ndk/issues/442
Bug: crashpad:30
Change-Id: I98c10e2eda773cb6f3d9eb8db9b8bfde43c885e7
Reviewed-on: https://chromium-review.googlesource.com/705674
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
One more for Windows too: compat/win/sys/time.h.
Bug: crashpad:30
Change-Id: I1f11933a5937a65db10774d0710d44dc85f8586a
Reviewed-on: https://chromium-review.googlesource.com/705278
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
