- 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>
- 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>
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>
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>
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>
Previously, the __ANDROID_API__ macro was provided by
<android/api-level.h>. With unified headers (expected to become the
default in the next NDK release and the sole option in the subsequent
release), this macro is not set properly by headers. When building with
Clang, the standalone toolchain’s clang and clang++ wrappers set the
macro properly. GCC isn’t accounted for in this way, so the build system
must assume the responsibility of setting it.
This change fishes the value of __ANDROID_API__ out of the standalone
toolchain’s clang wrapper and sets the android_api_level GYP variable
appropriately. From there, it will be picked up by common.gypi in
mini_chromium and used to define __ANDROID_API__.
This updates mini_chromium to 62e6015f633dd4acb1610db15a064889315cadaa
which understands this new GYP variable.
62e6015f633d android: Support “unified headers” with GCC build
https://android.googlesource.com/platform/ndk/+/master/docs/UnifiedHeaders.mdhttps://android.googlesource.com/platform/ndk/+/ndk-r14/CHANGELOG.md
Bug: crashpad:30
Change-Id: I33e66eba8394e32ced8dca80c8226b85e0e786f3
Reviewed-on: https://chromium-review.googlesource.com/458021
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
This is co-dependent with
https://chromium-review.googlesource.com/457736.
I’ve been trying to share a source tree between different platforms,
using gyp_crashpad.py --generator-output to put the build output in the
right place. On Windows, it winds up in
out\win\out\{Debug,Release}{,_x64}. This makes it tricky to use
run_tests.py, which expects to find build output right in the “out”
directory. It’s not impossible to use, because you can tell it
“win\out\Debug_x64”, but it’s really awkward to use that path when we
all know that it’s not relative to anything that makes sense, like the
current directory.
This simplifies run_tests.py to work directly with the
configuration-specific output directory. For most users, this means
including “out/” or “out\” when running the script.
Bug: chromium:703890
Change-Id: Ic7de82fabd2adda7ae00558844cb3ce91aa4a5ed
Reviewed-on: https://chromium-review.googlesource.com/457716
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
-Wmultichar is enabled by default with GCC (but not clang). It is
impossible to disable this warning with #pragma GCC diagnostic ignored.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
While compiling, for example, minidump_file_writer.cc:
In file included from ../../minidump/minidump_extensions.h:25:0,
from ../../minidump/minidump_file_writer.h:27,
from ../../minidump/minidump_file_writer.cc:15:
../../util/misc/pdb_structures.h:45:38: error: multi-character character constan
t [-Werror=multichar]
static const uint32_t kSignature = '01BN';
^~~~~~
../../util/misc/pdb_structures.h:106:38: error: multi-character character consta
nt [-Werror=multichar]
static const uint32_t kSignature = 'SDSR';
^~~~~~
../../minidump/minidump_file_writer.cc:190:23: error: multi-character character
constant [-Werror=multichar]
header_.Signature = MINIDUMP_SIGNATURE;
^~~~~~~~~~~~~~~~~~
doc/developing.md is also updated to provide GCC build instructions for
Android.
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: I9e7993761f5461281c9f4d8b4c56e8407e2c5b47
Reviewed-on: https://chromium-review.googlesource.com/409776
Reviewed-by: Robert Sesek <rsesek@chromium.org>
crashpad and mini_chromium both have top-level “build” directories.
These would conflict with top-level “BUILD” files in google3 when
checked out on a case-sensitive filesystem. Although Crashpad’s “build”
directory can be moved easily, mini_chromium’s matches Chromium’s, which
is much more difficult to move. “build” is also the best and most
obvious name for these directories.
To avoid this problem, in the external-dependencies build, crashpad and
mini_chromium are placed one level deeper, just as crashpad is in
Chromium, and mini_chromium is in the standalone Crashpad build. This
allows true pristine unmodified copies to be checked in to google3,
without comingling locally-added files such as BUILD with external
source.
The directory structure adopted for the external-dependencies build is
now
root/crashpad/crashpad[/README]
root/gmock[/include/gmock/gmock.h]
root/gtest[/include/gtest/gtest.h]
root/gyp[/pylib/gyp]
root/mini_chromium/mini_chromium[/build/common.gypi]
Change-Id: Idbc8f1b0d87da0cbceab3c15e059e839c1fb6a3f
Reviewed-on: https://chromium-review.googlesource.com/323991
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This augments the standalone and in-Chromium models with an external
model, in which the dependencies and Crashpad are checked out as
siblings in the same directory, organized according to this structure:
root/crashpad[/README]
root/gmock[/include/gmock/gmock.h]
root/gtest[/include/gtest/gtest.h]
root/gyp[/pylib/gyp]
root/mini_chromium[/build/common.gypi]
This is the directory structure used in google3.
Change-Id: Ie300ead7cd085265933e4ed891509ce050e995e2
Reviewed-on: https://chromium-review.googlesource.com/324230
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Oops, was passing the out dir (...\crashpad\out), not the binary dir
(...\crashpad\out\Debug). Didn't notice because I was running the
script directly, rather than via run_tests.py. :/
R=mark@chromium.org
BUG=crashpad:46
Review URL: https://codereview.chromium.org/1394343005 .
I'd like to write some `expect(1)`-style tests (possibly using
http://pexpect.readthedocs.org/en/stable/) to verify that various windbg
commands that I'm adding support for do actually work when consuming
minidumps in real life.
For the moment, this is just the beginnings of a stub as I don't know if
bots even have windbg/cdb installed.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46, crashpad:52
Review URL: https://codereview.chromium.org/1396943002 .
Removes the bitness-specific targets in favour of pulling binaries from
the other build directory. This is to avoid the added complexity of
duplicating all the targets for the x86 in x64 build.
Overall, mostly templatizing more functions to support the
wow64-flavoured structures. The only additional functionality required
is reading the x86 TEB that's chained from the x64 TEB when running
as WOW64.
The crashing child test was switched to a manual CreateProcess because
it needs to launch a binary other than itself.
R=mark@chromium.org
BUG=crashpad:50
Review URL: https://codereview.chromium.org/1349313003 .
This replaces the registration server, and adds dispatch to a delegate
on crash requests.
(As you are already aware) we went around in circles on trying to come
up with a slightly-too-fancy threading design. All of them seemed to
have problems when it comes to out of order events, and orderly
shutdown, so I've gone back to something not-too-fancy.
Two named pipe instances (that clients connect to) are created. These
are used only for registration (which should take <1ms), so 2 should be
sufficient to avoid any waits. When a client registers, we duplicate
an event to it, which is used to signal when it wants a dump taken.
The server registers threadpool waits on that event, and also on the
process handle (which will be signalled when the client process exits).
These requests (in particular the taking of the dump) are serviced
on the threadpool, which avoids us needing to manage those threads,
but still allows parallelism in taking dumps. On process termination,
we use an IO Completion Port to post a message back to the main thread
to request cleanup. This complexity is necessary so that we can
unregister the threadpool waits without being on the threadpool, which
we need to do synchronously so that we can be sure that no further
callbacks will execute (and expect to have the client data around
still).
In a followup, I will readd support for DumpWithoutCrashing -- I don't
think it will be too difficult now that we have an orderly way to
clean up client records in the server.
R=cpu@chromium.org, mark@chromium.org, jschuh@chromium.org
BUG=crashpad:1,crashpad:45
Review URL: https://codereview.chromium.org/1301853002 .
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
When building in the Chromium tree, this swaps out Crashpad’s copies of
mini_chromium, gtest, and gmock for the equivalents provided by
Chromium. A GYP variable, crashpad_in_chromium, is used to determine the
behavior.
gclient doesn’t sync sub-DEPS, so when doing an in-Chromium build,
Crashpad’s copies of mini_chromium, gtest, and gmock are not available.
BUG=crashpad:12
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/986033002
Test code that requires test data should call Paths::TestDataRoot() to
obtain the test data root. This will use the CRASHPAD_TEST_DATA_ROOT
environment variable if set. Otherwise, it will look for test data at
known locations relative to the executable path. If the test data is not
found in any of these locations, it falls back to using the working
directory, the same as the current behavior.
BUG=crashpad:4
TEST=crashpad_util_test Paths.TestDataRoot and others
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/992503002
In Chromium, many targets are built, sharing a single output directory.
Collisions are likely. When integrating Crashpad into Chromium, the
ui/snapshot library and Crashpad’s snapshot library were found to
conflict.
This change gives most Crashpad targets a “crashpad_” prefix to avoid
conflicts. All library and test targets are given a target_name with
this prefix. Existing tools are not likely to conflict with anything
else and are not given a prefix.
BUG=crashpad:12
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/990553003
When building in the Chromium tree, chromium_code is necessary to apply
Chromium’s build/filename_rules.gypi. Crashpad’s build depends on these
rules. chromium_code also enables a high warning level, which is
desirable for Crashpad.
BUG=crashpad:12
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/986873002
This commit contains the basic structure of the project:
- LICENSE and related files.
- DEPS to check dependencies out into third_party.
- README.crashpad files and .gyp files to accompany third_party
dependencies.
- Infrastructure to run GYP as a gclient hook.
- codereview.settings to enable Rietveld code review.
- Assorted other administrative and dot-files.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/426403002
