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>
end_to_end_test.py was producing these error messages 6 times (32-bit
x86) and 7 times (x86_64) per run:
[pid:tid:yyyymmdd,hhmmss.mmm:ERROR file_io.cc:89] ReadExactly: expected
36, observed 0
These messages were being produced by crashpad_handler, in the
LoggingReadFileExactly() call in
ExceptionHandlerServer::ServiceClientConnection().
sizeof(ClientToServerMessage) is 36. crashpad_handler believed that a
client was connecting, but the client sent no data.
This was tracked down to the use of os.path.exists() in
end_to_end_test.py to wait for crashpad_handler’s named pipe to be
created. Checking named pipe existence in this way appeared to be a
client connecting to the the pipe server in crashpad_handler, although
of course no real client was connecting and no message was forthcoming.
I found that running “dir” on the named pipe’s path produced the same
result.
Using WaitNamedPipe() is an alternative that can be used to signal when
the named pipe’s path exists. Furthermore, it tests more than mere
creation, it indicates that the pipe server has become ready to service
clients. That’s not necessary in this case as proper clients already
need to deal with this on their own, but checking it in
end_to_end_test.py should be harmless.
Test: end_to_end_test.py
Change-Id: Ida29a3d2325368f58930cdf8fb053449f621ea52
Reviewed-on: https://chromium-review.googlesource.com/703276
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
|ranges| is a coalesced list of committed and accessible memory ranges
trimmed to reflect only those that overlap |range|. |range| is only
fully unreadable if |ranges| is empty. If |ranges| contains more than
one element, it indicates that |range| is sparse (since |ranges| is
coalesced, there must be a “hole”). This should be treated as partially
unreadable, the same as when |ranges[0]| doesn’t begin or end where
|range| does.
Test: self_destroying_test_program.exe (via end_to_end_test.py)
Change-Id: I55fc2b201089113f2b07395e352704b99d212801
Reviewed-on: https://chromium-review.googlesource.com/702535
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
In the 64-bit version of the structure, padding is needed between
ShowWindowFlags and WindowTitle.
The CurrentDirectores (yes, that’s how it’s spelled) members would have
been interpreted incorrectly because STRING was defined incorrectly. The
length fields are USHORT, not DWORD. In the 64-bit version of the
structure, a padding member ensured that the structure was at least the
correct size. In the 32-bit version of the structure, this caused the
structure size to be inflated, so all but the first CurrentDirectores
element and any struct member that followed would appear at incorrect
offsets, and the overall struct size being read was larger than
appropriate.
This resolves crashpad_handler logging (usually) three errors while
handling a 64-bit process crash, such as:
[pid:tid:yyyymmdd,hhmmss.mmm:ERROR process_info.cc:632] range at
0x780f24de00000000, size 0x275 fully unreadable
[pid:tid:yyyymmdd,hhmmss.mmm:ERROR process_info.cc:632] range at
0x780f24fe00000000, size 0x275 fully unreadable
[pid:tid:yyyymmdd,hhmmss.mmm:ERROR process_info.cc:632] range at 0x0,
size 0x275 fully unreadable
Bug: crashpad:198
Test: end_to_end_test.py
Change-Id: I1655101de01cf46b4b50eda45a11f8d0f3bca8b3
Reviewed-on: https://chromium-review.googlesource.com/701736
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
