Some crash recorders respond with non-200 2xx responses on success, e.g.
HockeyApp which responds with 202 Accepted.
Change-Id: I40de12155b44f7638a1c726090657938e3b1b557
Reviewed-on: https://chromium-review.googlesource.com/1167793
Commit-Queue: Jeremy Apthorp <jeremya@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The C++ http_transport_test_server was added in 439ba730c5ae and the
missing GYP build description was corrected in 0e144fb9aeff, but this
wasn’t complete for Windows. ws2_32.lib was missing.
Bug: crashpad:227
Change-Id: I2a0810468f857a02ad1a997c569eee6d9c05c7da
Reviewed-on: https://chromium-review.googlesource.com/1167210
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
__aarch64__ should always be defined for 64-bit ARM, while __arm64__
only sometimes is.
Change-Id: I46a6469d8f5e74ad79b6ded51a809fbf88e5170a
Reviewed-on: https://chromium-review.googlesource.com/1151541
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
The general strategy used by Crashpad to determine loaded modules is to
read the link_map to get the addresses of the dynamic arrays for all
loaded modules. Those addresses can then be used to query the MemoryMap
to locate the module's mappings, and in particular the base mapping
from which Crashpad can parse the entire loaded ELF file.
ELF modules are typically loaded in several mappings with varying
permissions for different segments. The previous strategy used to find
the base mapping for a module was to search backwards from the mapping
for the dynamic array until a mapping from file offset 0 was found for
the same file. This fails when the file is mapped multiple times from
file offset 0, which can happen if the first page of the file contains
a GNU_RELRO segment.
This new strategy queries the MemoryMap for ALL mappings associated
with the dynamic array's mapping, mapped from offset 0. The consumer
(process_reader_linux.cc) can then determine which mapping is the
correct base by attempting to parse a module at that address and
corroborating the PT_DYNAMIC or program header table address from the
parsed module with the values Crashpad gets from the link_map or
auxiliary vector.
Bug: crashpad:30
Change-Id: Ibfcbba512e8fccc8c65afef734ea5640b71e9f70
Reviewed-on: https://chromium-review.googlesource.com/1139396
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
These fixes are mostly related to address sanitizer causing stack
variables to not be stored on the call-stack. Attempting to disable
safe-stack has no effect.
Change-Id: Ib5718bfb74ce91dee560b397ccdbf68d78e4ec6a
Reviewed-on: https://chromium-review.googlesource.com/1140507
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
When building in chromium, the test is linked into the crashpad_tests
target instead of crashpad_util_test.
Change-Id: I4e0f6b9956f191ebac10f0aaa3812e30885a4e0a
Reviewed-on: https://chromium-review.googlesource.com/1131688
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
We are transitioning to a token-based API and will be removing the
old one.
Changes to use a thread state wait rather than reading the registers in
a loop to determine when the thread is actually suspended.
Change-Id: I4b015bb0fc74b15177304a62be6c1d9a59b45c80
Reviewed-on: https://chromium-review.googlesource.com/1100170
Commit-Queue: Brett Wilson <brettw@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
openssl outputs some useless junk when generating the test key; swallow
that.
'''
Generating a 2048 bit RSA private key
...............................................+++
...........................................+++
writing new private key to 'crashpad_util_test_key.pem'
-----
'''
Bug: crashpad:196
Change-Id: I0bdfb4f29931ef58d0c51c5e5488d3b5aeb798f0
Reviewed-on: https://chromium-review.googlesource.com/1099960
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Sanitization is controlled by a SanitizationInformation struct to be
read from the client's memory. The address of this struct is either
passed in a ClientInformation when the client requests a crash dump,
or as a flag to the handler --sanitization_information.
Bug: crashpad:30
Change-Id: I2744f8fb85b4fea7362b2b88faa4bef1da74e36b
Reviewed-on: https://chromium-review.googlesource.com/1083143
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
A ProcessSnapshotSanitized enables filtering possibly sensitive
information from a snapshot.
WebView has different privacy constraints than Chrome and needs to
avoid collecting data in annotations or from stack memory that may
contain PII. This CL enables:
1. Filtering annotations by name using a whitelist.
2. Filtering for crashes which reference a particular module.
3. Redacting non-essential information from stack memory.
This CL does not provide a client interface to enable sanitization.
Bug: crashpad:30
Change-Id: I8944c70fdcca6d6d4b7955d983320909bf871254
Reviewed-on: https://chromium-review.googlesource.com/1070472
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Depend on the BoringSSL target instead of the libs when building in the
Fuchsia tree.
Bug: crashpad:196
Change-Id: Ib1faa9335eedff1fd9dd072234df2d48612ab423
Reviewed-on: https://chromium-review.googlesource.com/1079434
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Officially, register X31 does not exist. The code is zeroing out a location
and thus actually needs XZR.
LLVM seems to automatically translate X31 into XZR when compiling the code,
but GCC (tested 7.3.0) refuses to accept the instruction:
../../third_party/crashpad/crashpad/util/misc/capture_context_linux.S: Assembler messages:
../../third_party/crashpad/crashpad/util/misc/capture_context_linux.S:291: Error: operand 1 must be an integer register -- `str x31,[x0,#0xb0]'
Bug: chromium:819294
Change-Id: I85be3923ac56fca6e3ec59d7e22b2223cfc8fa63
Reviewed-on: https://chromium-review.googlesource.com/1078818
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
With use_boringssl_for_http_transport_socket set, this also works on
Linux, however the bots fail during run lacking libcrypto.so.1.1. So,
not enabled on Linux until that's figured out.
(Includes https://github.com/yhirose/cpp-httplib/pull/70, until it lands
and I'll do a full roll of cpp-httplib then.)
Bug: crashpad:30, crashpad:196
Change-Id: I987f6a87f8e47160c15e53fe1ce28611339069ff
Reviewed-on: https://chromium-review.googlesource.com/1075726
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Because of Fuchsia's scheduler the seemingly reasonable time check fails
occasionally.
Bug: crashpad:196, crashpad:231
Change-Id: Ic212a50e73e283ce3d279dd8c28adecbc432e39c
Reviewed-on: https://chromium-review.googlesource.com/1055805
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Also exclude http_transport_test_server from Android where it doesn't
build.
Change-Id: I51cc3f50e4fb9db982d91b2924b8ea87d86926d4
Reviewed-on: https://chromium-review.googlesource.com/1054160
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Packaged test running seems to be a ways off, but with a bit of path
fiddling in test_paths.cc we can actually use the paths where the tests
are copied, so do that instead to get all the tests re-enabled. The
setup in BUILD.gn should be mostly-useful once packaging is working as
all helper/data files will need to specified there anyway.
Also, attempted fix to flaky behaviour in
ProcessReaderFuchsia.ChildThreads exposed because the tests are now
being run. zx_object_wait_many() waits on *any* of the objects, not
*all* of them. Derp!
And finally, for the same test, work around some unintuitive behaviour
in zx_task_suspend(), in particular that the thread will not be
suspended for the purpose of reading registers right away, but instead
only "sometime later", which appears in pratice to be after the next
context switch. Have ScopedTaskSuspend block for a while to try to
ensure the registers become readble, and if they don't, at least fail
noisily at that point.
Bug: crashpad:196
Change-Id: I01fb3590ede96301c941c2a88eba47fdbfe74ea7
Reviewed-on: https://chromium-review.googlesource.com/1053797
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
The package deployment/running is in flux at the moment. In order to get
all the other tests on to the main Fuchsia waterfall, disable the ~25
tests that require external files (for launching child processes,
loading modules, or data files) because those operations all fail on
Fuchsia-without-packages right now. Upstream this is PKG-46. Once test
packaging and running has been resolved, this can be reverted.
These tests are still run when building Crashpad standalone on Fuchsia
as the standalone build simply copies all the relevant data files to the
device in /tmp.
Bug: crashpad:196
Change-Id: I1677c394a2b9d709c59363ebeea8aff193d4c21d
Reviewed-on: https://chromium-review.googlesource.com/1045547
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Implements InitializeException() in ProcessSnapshot, and pulls it all
together writing the dump in crash handler. Sample output at crash
00163eff624e653e on the staging server.
Also adds a child-retrieve helper to koid_utilities.
Bug: crashpad:196
Change-Id: I4bee7655e81e3243ac0ae896ff0caea7ce4acdad
Reviewed-on: https://chromium-review.googlesource.com/1044771
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When binding to an exception port on Fuchsia, a key is supplied and
passed back to coordinate between the registerer and the handler.
An arbitrary value is used by both devmgr:
https://fuchsia.googlesource.com/zircon/+/HEAD/system/core/devmgr/devmgr.c#203
and by crashlogger:
https://fuchsia.googlesource.com/zircon/+/HEAD/system/core/crashlogger/crashlogger.cpp#149 .
In order to be able to have crashpad_handler be a drop-in for
crashlogger (at least for now), Crashpad will use this same key in
subsequent patches for this purpose. Pull this value out in a header so
it can be shared by different bits that will need to refer to it.
Bug: crashpad:196
Change-Id: I00e0178156a792bd80fc83b1b7d85b5ce6742e9a
Reviewed-on: https://chromium-review.googlesource.com/1038123
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Of course, as soon as I tried it against the real endpoint on Fuchsia,
the server just spits out raw crash id as a string without specifying
Content-Length.
Bug: crashpad:196, crashpad:30
Change-Id: I22af87589a8801cdfece0a7b862e70e0e7097f1f
Reviewed-on: https://chromium-review.googlesource.com/1024953
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Partial implementation: Currently only handles http (i.e. no TLS), only
POST, and only certain response types (only when Content-Length is
specified, and not chunked). Used for Linux and Fuchsia lacking anything
better (that's shippable). Removes libcurl HTTPTransport, since it isn't
available in the Chromium sysroot anyway.
This is an intermediate step until BoringSSL is available in the Fuchsia
SDK. Once that's available, it should be "relatively straightfoward" to
make http_transport_socket.cc secure its socket using BoringSSL or
OpenSSL depending on the platform.
Bug: crashpad:196, crashpad:227, crashpad:30
Change-Id: If33a0d3f11b9000cbc3f52f96cd024ef274a922f
Reviewed-on: https://chromium-review.googlesource.com/1022717
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Copied from the _linux implementation, which looks close to what
ucontext on Fuchsia is (though it will probably need to change).
In arm64 debug, CaptureContext.CaptureContext requires slightly longer
slop distance.
Bug: crashpad:196
Change-Id: I2a6f90095e06fe8b468fbfd8add66a73c8a1d92f
Reviewed-on: https://chromium-review.googlesource.com/1031091
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
- Use "deprecated_system_image" (merging from downstream)
- Add package for crashpad_handler
- Depend on launchpad target instead of a lib when in tree, as launchpad
is no longer in the sysroot.
- Don't try to remove the -Wexit_time_destructors unless building
standalone, when it's added by mini_chromiums BUILDCONFIG.gn
Bug: crashpad:196
Change-Id: I08e0faaa989346b078a41896eb4ace69e7b1bcdc
Reviewed-on: https://chromium-review.googlesource.com/1026514
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
- Pulls in cpp-httplib for test-only usage in third_party/.
- Replaces http_transport_test_server.py with .cc server.
- Remove unnecessary Go toolchain pull. This was planned to be used for
the test server, but the toolchain integration was too messy when
covering all target platforms/configs.
Bug: crashpad:196, crashpad:227, crashpad:30
Change-Id: I5990781473dcadfcc036fbe711c02928638ff851
Reviewed-on: https://chromium-review.googlesource.com/1013293
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Building Crashpad with GCC flagged a few potential issues. The issues
don't seem particularly severe, but they are easy enough to fix.
Note that even with these changes, Crashpad will not cleanly build with
GCC (additional patches would be needed to third_party/mini_chromium).
Bug: crashpad:
Change-Id: I9289d6c918da9a111aa3c2a078ad0dc1ba84749f
Reviewed-on: https://chromium-review.googlesource.com/1014280
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Leonard Mosescu <mosescu@chromium.org>
This is a very basic form of URL cracking to break a
HTTPTransport::SetURL() argument up into component parts. This is split
out of the (upcoming)
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1008407
for Linux and Fuchsia.
Bug: crashpad:196
Change-Id: Iba075d9c8720c14550ce53e23d684362da84740c
Reviewed-on: https://chromium-review.googlesource.com/1010972
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This implementation has some limitations as documented in the header,
however, threads must be suspended in order to use the register capture
debug API so this is somewhat useful for now in the context of
generate_dump.
Also, refactor some child-object retrieval helpers used in a few places.
Bug: crashpad:196
Change-Id: I1fdae5fc3d4b43841e535724eac10c1e58af04c5
Reviewed-on: https://chromium-review.googlesource.com/1007966
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
uc_mcontext.fpregs is a pointer to the floating point context, but
CaptureContext() doesn't yet capture floating point context.
This error manages to slip by unit tests when run all together, but
fails when CrashpadClient.SimulateCrash is run by itself.
Bug: crashpad:30
Change-Id: I7adc30648642912d66a7ba8cf9973c9bc0fbd8bc
Reviewed-on: https://chromium-review.googlesource.com/1011504
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Add pid->handle mapping code to generate_dump. This is enough to get
generate_dump to start capturing a dump for an arbitrary system process.
It currently CHECK()s in ProcessSnapshotFuchsia on some unimplemented
functionality.
Bug: crashpad:196
Change-Id: Idfbaa4fbf32af63ad6db5b0b78a7a1991b82728e
Reviewed-on: https://chromium-review.googlesource.com/1005804
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Fuchsia enables safe-stack by default in the compiler. Disable it for
the test function so that a candidate RSP value can be found by using
the value of locals on the stack.
(This also reduces the function prolog size sufficiently for the PC
comparison to work, otherwise it required 75 bytes for the delta
comparison.)
Bug: crashpad:196
Change-Id: I2adbcee93c90dbc415309b79e3d16e9c4635f989
Reviewed-on: https://chromium-review.googlesource.com/1000140
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This change:
1. Updates the broker's memory reading protocol to enable short reads.
2. Updates Ptracer to allow short reads.
3. Updates the broker to allow reading from a memory file.
4. Updates the broker's default file root to be "/proc/[pid]/".
5. Adds PtraceConnection::Memory() to produce a suitable memory reader
for a connection type.
Bug: crashpad:30
Change-Id: I8c004016065d981acd1fa74ad1b8e51ce07c7c85
Reviewed-on: https://chromium-review.googlesource.com/991455
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
user_vfp is not declared anymore in sys/user.h, but in specific
internal kernel asm user.h in GLIBC. So building crashpad on ARMEL
with such a GLIBC will fail to build.
Also, sys/ptrace.h will not include the declarations for
PTRACE_GET_THREAD_AREA and PTRACE_GETVFPREG in arm (they are in
asm/ptrace.h and not included from sys/ptrace.h). So provide
compatibility declarations accordingly for arm architecture.
Change-Id: I58ab5274a66d84c0cbc9e9e9b23e0abc37bf67e5
Reviewed-on: https://chromium-review.googlesource.com/996073
Reviewed-by: Mark Mentovai <mark@chromium.org>
Some files, such as /proc/[pid]/maps, may not be accessible to the
handler. This enables the handler access to the contents of those files
via the broker.
This change reads maps and auxv using ReadFileContents.
Bug: crashpad:30
Change-Id: Ia19b498bae473c616ea794ab51c3f22afd5795be
Reviewed-on: https://chromium-review.googlesource.com/989406
Reviewed-by: Mark Mentovai <mark@chromium.org>
1. Prefix enable_http_transport_libcurl with crashpad for use in
chromium .gn files.
2. Make tools build on Android using http_transport_none.cc
Bug: crashpad:30
Change-Id: I0a9878fe9f5b8fbc13a52f93df273fb1de8160f3
Reviewed-on: https://chromium-review.googlesource.com/984038
Reviewed-by: Mark Mentovai <mark@chromium.org>
Also fix an error in checking that PtraceClient was initialized.
Bug: crashpad:30
Change-Id: I1928340a2a642c2d831f0152bb9faaa12afb07e8
Reviewed-on: https://chromium-review.googlesource.com/978630
Reviewed-by: Mark Mentovai <mark@chromium.org>
When building in chromium, executables and loadable_modules should
depend on:
//build/config:exe_and_shlib_deps
which, among other things, may be needed to introduce a
dependency on a custom libc++.
Bug: crashpad:30
Change-Id: Ic46a3cf5b46bdac09cca22950f9236e0776ba44a
Reviewed-on: https://chromium-review.googlesource.com/974713
Reviewed-by: Mark Mentovai <mark@chromium.org>
glibc 2.26 defines ucontext_t from a struct ucontext_t while Bionic
and older versions of glibc use a struct ucontext.
Bug: crashpad:30
Change-Id: I473c317dbdbbedfad601c7594cfa7df7f7c01cb9
Reviewed-on: https://chromium-review.googlesource.com/972613
Reviewed-by: Mark Mentovai <mark@chromium.org>
The implementations requires NUL-termination for the underlying buffer,
so just use std::string everywhere, rather than trying to detect whether
strings are already NUL-terminated.
Bug: chromium:817982, chromium:818376
Change-Id: I4c8dcb5ed15ebca4c531f9a5d0ee865228dc0959
Reviewed-on: https://chromium-review.googlesource.com/947742
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
These flags were moved to mini_chromium's build/BUILD.gn, but that
configuration is not present when building in chromium.
Change-Id: I0d03c7461869882cf2ee7544ecd3d100eb189160
Reviewed-on: https://chromium-review.googlesource.com/940436
Reviewed-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
CrashpadClient will need ScopedPrSetPtracer when launching a handler
process in response to a crash.
Bug: crashpad:30
Change-Id: I35bc784b948349ca771f9cd65ef1089e626976bb
Reviewed-on: https://chromium-review.googlesource.com/927352
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Fuchsia does not currently support any sort of file locking. Until a
lock server can be implemented, compile out the calls to flock(). In the
one current non-test user of locking (Settings) add a
pseudo-implementation that will DCHECK if there is ever contention on
the lock.
Bug: crashpad:217, crashpad:196
Change-Id: Ifdf7e00886ad7e7778745f1ae8f0ce2a86f0ae3b
Reviewed-on: https://chromium-review.googlesource.com/924312
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Fuchsia errors out in rename() when source == dest. I believe this is
incorrect according to
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html,
but it's also relatively easy to work around in our code, and this fixes
CrashReportDatabaseTest.RequestUpload.
This is ZX-1729 upstream.
Bug: crashpad:196
Change-Id: I27473183b04484e146a7bd9e87e60be3aeff1932
Reviewed-on: https://chromium-review.googlesource.com/923708
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Embeds the address of g_crashpad_info into a .note section (which is
readable by the generic code to read notes in ElfImageReader).
Unfortunately because the note section is in libclient.a, it would
normally be dropped at link time. To avoid that, GetCrashpadInfo() has
a reference *back* to that section, which in turn forces the linker to
include it, allowing the note reader to find it at runtime.
Previously, it was necessary to have the embedder of "client" figure out
how to cause `g_crashpad_info` to appear in the final module's dynamic
symbol table. With this new approach, there's no manual configuration
necessary, as it's not necessary for the symbol to be exported.
This is currently only implemented in the Linux module reader (and I
believe the current set of enabled tests aren't exercising it?) but it
will also be done this way for the Fuchsia implementation of
ModuleSnapshot.
Bug: crashpad:196
Change-Id: I599db5903bc98303130d11ad850ba9ceed3b801a
Reviewed-on: https://chromium-review.googlesource.com/912284
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This change updates CrashReportDatbase::NewReport objects to own the
file handle associated with the new report, now accessible via a
FileWriter. NewReport's destructor closes its file handle and removes
its new report unless disarmed with FinishedWritingCrashReport,
eliminating the need for CallErrorWritingCrashReport.
Bug: crashpad:206
Change-Id: Iccb5bbc0ebadb07a237ff8eb938389afcfeae2a5
Reviewed-on: https://chromium-review.googlesource.com/916941
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Split out of crrev.com/c/689745 by jperaza, with a simple test added.
It is useful for this to be an overload instead of a separate signature
so that code that extracts a UUID string out of a filename can treat it
generically between Windows and non-Windows.
Bug: crashpad:196, crashpad:206
Change-Id: I0d7d84a93d9526d1aae8839179dfe903acca091b
Reviewed-on: https://chromium-review.googlesource.com/916885
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Pending a definition of NativeCPUContext, and an implementation of
CaptureContext().
Bug: crashpad:196
Change-Id: Ibd7721cb740d7662379bb6b22e7804738e16c724
Reviewed-on: https://chromium-review.googlesource.com/916902
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Previously, an error would have been logged twice.
Bug: crashpad:30
Change-Id: I9445c022550ad14497186c6878863fbf72d8cd59
Reviewed-on: https://chromium-review.googlesource.com/911822
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Previously, the mac version was under client/ and win under util/win/.
This cl brings them all together under util/misc/ and combines common
test code.
Bug: crashpad:30
Change-Id: Idf0d0158b969d5aa9802dfc8c21f73041b2bcc6c
Reviewed-on: https://chromium-review.googlesource.com/907755
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
- default to subsystem:console
- don't build posix/timezone.*
- add some missing libs
This gets all the main binaries building and running. Most configs pass,
but there's some offsets that seem different in some builds; need to
investigate more. Additionally, the binaries used by end_to_end_test.py
aren't yet built, so that script fails.
Includes mini_chromium roll to 46eeaf9:
46eea49 gn win: Add debug info and pdb to cc/cxx
902a29f gn win: Various fixes towards making GN build work
Bug: crashpad:79
Change-Id: Ie56a469b84bed7b0330172cec9f1a8aeb95f702e
Reviewed-on: https://chromium-review.googlesource.com/902403
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Avoids using pointers shared between parent/child. Explicitly builds the
test strings in the child process, and then passes both the address and
the expected value of the string to the parent process for expectation
checking. This is necessary to have the test work on Fuchsia.
Also renames ...Forked to ...Child.
Bug: crashpad:196, crashpad:215
Change-Id: I7f22c134301a2806eb39549e371414e7ec9bf225
Reviewed-on: https://chromium-review.googlesource.com/896228
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Avoids fork()ing as per previous tests in this file, necessary for
Fuchsia.
Unfortunately, I believe that mmap()/munmap() aren't actually working
correctly on Fuchsia as tested by the EXPECT_FALSE reads, and so these
tests incorrectly fail. Bug with repro filed upstream at ZX-1631.
Bug: crashpad:196, crashpad:215
Change-Id: Iec86f64fcee12097223326f2bf2d5a5348a8a610
Reviewed-on: https://chromium-review.googlesource.com/894124
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Bionic uses negative values of a semaphore to represent contention.
`sem_timedwait` fails to restore the value to 0 on timeout resulting in
an error (EBUSY) upon calling `sem_destroy`.
Bug: crashpad:30
Change-Id: If1c73a54a879ebd003b0792ebb8f68ceb83ac8bb
Reviewed-on: https://chromium-review.googlesource.com/894106
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Instead of using pointers shared between the parent/child due to fork,
explicitly builds and passes them between processes. This is
unfortunately a bit more verbose, but seems like it tests functionality
a little better, and is required to have the test work on Fuchsia.
Also renames the ...Forked to ...Child to be correct after the change
from Multiprocess to MultiprocessExec.
Bug: crashpad:196, crashpad:215
Change-Id: I610a7f1e35b6513805c27d9e610f7a9b9820cabc
Reviewed-on: https://chromium-review.googlesource.com/892286
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Instead of allocating test memory in the parent and then forking and
comparing against it, the child does the allocation and passes back the
region's size and address. Additionally, switch the memcmp()s to be
value-based comparisons instead because the region isn't available in
the parent.
Also renames ProcessMemory.ReadForked to .ReadChild to be correct after
the change from Multiprocess to MultiprocessExec.
This is necessary to have the tests work on Fuchsia.
Bug: crashpad:196, crashpad:215
Change-Id: Id996a21180d87c7f2556283e9f54f6128726f9b8
Reviewed-on: https://chromium-review.googlesource.com/892102
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Change-Id: I062c853d65c3e89a61920d790d9bc5c993b46fcd
Reviewed-on: https://chromium-review.googlesource.com/884581
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
(Still need to avoid fork()-dependence for the non-self tests.)
Bug: crashpad:196
Change-Id: Ib34fe33c7ec295881c1f555995072d9ff742647f
Reviewed-on: https://chromium-review.googlesource.com/876650
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
ProcessMemory::ReadCStringInternal needs to be able to perform short
reads.
Change-Id: I2b2e1c2e6603d01235d8d2dbd15494375cd7f3f6
Reviewed-on: https://chromium-review.googlesource.com/874776
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Use the "POSIX" implementation of ThrowBadAlloc() on Windows when libc++
is being used.
Bug: chromium:801780
Change-Id: I230a8df9040aa73e290bb0d002996e822958a94b
Reviewed-on: https://chromium-review.googlesource.com/872121
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
This supports multiprocess tests of the non-fork() variety.
Also, improve directory finding so that the
crashpad_test_test_multiprocess_exec_test_child binary can be located
correctly on Fuchsia.
Doc ref for launchpad:
https://fuchsia.googlesource.com/zircon/+/master/system/ulib/launchpad/include/launchpad/launchpad.h#23
Also, roll mini_chromium to pick up ScopedZxHandle addition. Includes:
a19ef08 Merge ScopedZxHandle from Chromium base
f21c900 fuchsia: Move zircon libs dep to base, rather than global
Bug: crashpad:196
Change-Id: Id01dee43f2d04e682e70c12777aff41f8dd848d6
Reviewed-on: https://chromium-review.googlesource.com/868967
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
With a companion mini_chromium change at https://crrev.com/c/841203,
it’s possible to configure via “gn args” as follows:
android_ndk = "/android/android-ndk-r16"
target_cpu = "x86_64"
target_os = "android"
Note that a standalone toolchain is not required.
Bug: crashpad:30, crashpad:79
Change-Id: Ica55bdcb82c730909c05dd9fecb40a74eca78c8a
Reviewed-on: https://chromium-review.googlesource.com/841286
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Otherwise, Chromium complains about ARCH_CPU_64_BITS usage without it.
Bug: crashpad:30
Change-Id: I4e10595280d309ae891266c03d0467c6c8471d4e
Reviewed-on: https://chromium-review.googlesource.com/835429
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
This is sufficient for a native Linux build using GN. Android is not yet
supported.
mini_chromium side: https://crrev.com/c/833407
This also updates mini_chromium to 404f6dbf9928.
c913ef97a236 gn, linux: Build for Linux with GN
404f6dbf9928 gn: Don’t use .rsp files; rationalize descriptions and
output dirs
Bug: crashpad:79
Change-Id: I4f3b72fd02884d77812e520fb95231b35815677d
Reviewed-on: https://chromium-review.googlesource.com/833408
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Goes with
https://chromium-review.googlesource.com/c/chromium/mini_chromium/+/833328.
Also roll mini_chromium:
scottmg@around:/work/crashpad/crashpad/third_party/mini_chromium/mini_chromium$ git log 20182dd263312db9fad52042fc92c33331ec6904..e182031 --oneline
e182031 gn: Add is_posix.gni to define local is_posix variable
4cb1344 gn: Enable proper release-mode optimizations for POSIX-non-Mac
9c0eb0c Remove reference to ptr_util.h
c5ae5aa gn: Configure the sysroot in target_sysroot, not sysroot
f7e5654 gn, mac: Honor mac_sdk_min, sysroot, and mac_deployment_target
7701901 Remove the deprecated sparse_histogram.h header.
e2f0160 Use Chromium copyright notice and BSD license in mini_chromium
Bug: crashpad:79, crashpad:196
Change-Id: Ie41d971e0e769db2ed18861da07021c071f6c650
Reviewed-on: https://chromium-review.googlesource.com/833329
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>
This is needed to make the “sysroot = "/"” configuration, which
translates to “sysroot = ""”, work properly
Bug: crashpad:79
Change-Id: I25ab49b7d57abfcf0ce9a62925013bb58dadf5dd
Reviewed-on: https://chromium-review.googlesource.com/831007
Reviewed-by: Scott Graham <scottmg@chromium.org>
Without this, attempting to roll crashpad in Chromium gives this
presubmit warning:
third_party/crashpad/crashpad/util/file/file_io_posix.cc:69
OS_FUCHSIA macro is used without including build/build_config.h.
R=mark@chromium.org
Bug: none
Change-Id: Ie2d1df574773b66687948a481b9b31012427a3c3
Reviewed-on: https://chromium-review.googlesource.com/830258
Commit-Queue: Ilya Sherman <isherman@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
- Remove unnecessary flags (O_NOCTTY, O_CLOEXEC)
- Don't try to unlink a directory when it's expected to fail
- Disable rmdir() in location where it's expected to fail, as it currently
(incorrectly) does not fail on Fuchsia.
Bug: crashpad:196, US-400
Change-Id: I80cf833ba90f31943b9043727ea07893b4eb3494
Reviewed-on: https://chromium-review.googlesource.com/823286
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
A PtraceBroker/Client pair implement a PtraceConnection over a socket.
The broker runs in a process with `ptrace` capabilities for the target
process and serves requests for the client over a socket.
Bug: crashpad:30
Change-Id: Ied19bcedf84b46c8f68440fd1c284b2126470e5e
Reviewed-on: https://chromium-review.googlesource.com/780397
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Removes the /BASE:N and /FIXED arguments to the child, which weren't
actually testing correctly (see bug), and were causing problems at least
on Win7 when something collided with that address.
Additionally, switches to storing modules in load order, rather than a
combination of memory order and initialization order, since that was a
bit confusing and there was no great rationale for it.
While reviewing, handle the case of a corrupted module name, and if it's
unreadable continue emitting "???" as a name. Adds a test for this
functionality.
Bug: chromium:792619
Change-Id: I2e95a81b02fe4d527868f6a5f980d315604255a6
Reviewed-on: https://chromium-review.googlesource.com/815875
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Stubs a variety of classes (CrashReportExceptionHandler,
ExceptionHandlerServer, HTTPTransport, CrashReportDatabase).
Bug: crashpad:196
Change-Id: I4772f90d0d2ad07cc2f3c2ef119e92fde5c7acef
Reviewed-on: https://chromium-review.googlesource.com/809940
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Scott Graham <scottmg@chromium.org>
Links, but various tests fail.
Also adds support to run_tests.py to run a single binary, likely only
useful on Fuchsia.
Bug: crashpad:196
Change-Id: Ie82ef26ec214ff4262194e877469953aa8fb367e
Reviewed-on: https://chromium-review.googlesource.com/809467
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
- Implement build/run_tests.py to run on Fuchsia device
- Implement paths_fuchsia.cc using standard Fuchsia namespace layout
- Exclude multiprocess tests, currently unimplemented
- Don't use unnecessary O_ flags on Fuchsia in open() call.
Bug: crashpad:196, chromium:726124, ZX-797
Change-Id: Ie59dce685b4c3fe54f3e36f357c1101d402ee8b7
Reviewed-on: https://chromium-review.googlesource.com/802180
Commit-Queue: Scott Graham <scottmg@chromium.org>
Reviewed-by: Mark Mentovai <mark@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>
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>
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>
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>
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 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>
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>
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>
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>
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 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>
../../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>
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>
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>
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>
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>
