sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This is a reland of 460943dd9a71dc76f68182a8ede766d5543e5341
Original change's description:
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
The reland isolates the change to non-Android POSIX systems because
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
Change-Id: If44629f5445bb0e3d0a1d3698b85f047d1cbf04f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3721655
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This reverts commit 460943dd9a71dc76f68182a8ede766d5543e5341.
Reason for revert: This fails to compile in Chromium Android.
posix_spawn and posix_spawnp are available in Android NDK 28, but
Chromium is building with version 23.
https://ci.chromium.org/ui/p/chromium/builders/try/android_compile_dbg/1179765/overview
Original change's description:
> posix: Replace DoubleForkAndExec() with ForkAndSpawn()
>
> The DoubleForkAndExec() function was taking over 622 milliseconds to run
> on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
> some custom traces and found that the fork() syscall is the bottleneck
> here, i.e., the first fork() takes around 359 milliseconds and the
> nested fork() takes around 263 milliseconds. Replacing the nested fork()
> and exec() with posix_spawn() reduces the time consumption to 257
> milliseconds!
>
> See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
> slow on macOS and why posix_spawn() is a better replacement.
>
> Another point to note is that even base::LaunchProcess() from Chromium
> calls posix_spawnp() on macOS -
> 8f8d82dea0:base/process/launch_mac.cc;l=295-296
>
> Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
> Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
> Reviewed-by: Mark Mentovai <mark@chromium.org>
> Commit-Queue: Mark Mentovai <mark@chromium.org>
Change-Id: I7f6161bc4734c50308438cdde1e193023ee9bfb8
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3719439
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
The DoubleForkAndExec() function was taking over 622 milliseconds to run
on macOS 11 (BigSur) on Intel i5-1038NG7. I did some debugging by adding
some custom traces and found that the fork() syscall is the bottleneck
here, i.e., the first fork() takes around 359 milliseconds and the
nested fork() takes around 263 milliseconds. Replacing the nested fork()
and exec() with posix_spawn() reduces the time consumption to 257
milliseconds!
See https://github.com/libuv/libuv/pull/3064 to know why fork() is so
slow on macOS and why posix_spawn() is a better replacement.
Another point to note is that even base::LaunchProcess() from Chromium
calls posix_spawnp() on macOS -
8f8d82dea0:base/process/launch_mac.cc;l=295-296
Change-Id: I25c6ee9629a1ae5d0c32b361b56a1ce0b4b0fd26
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3641386
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Sanitizers can prevent the installation of signal handlers, but
sigaction would still return 0 (for success). Detect this by checking
the installed signal handler via a second call to sigaction.
R=mark@chromium.org
Bug: chromium:1328749
Change-Id: I62a5777379ec5c6b1ca2d5a62e7cd3fb8ed1437b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3702302
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
* ATOMIC_FLAG_INIT is deprecated.
* Compound ops on volatiles are deprecated.
Bug: chromium:1284275
Change-Id: I2235662c00e4be8c5eba2aaf565663faf8d9576a
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3658639
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Use BUILDFLAG(IS_*) instead of defined(OS_*).
This was generated mostly mechnically by performing the following steps:
- sed -i '' -E -e 's/defined\(OS_/BUILDFLAG(IS_/g' \
-e 's%([ !])OS_([A-Z]+)%\1BUILDFLAG(IS_\2)%g' \
$(git grep -l 'OS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- sed -i '' -e 's/#ifdef BUILDFLAG(/#if BUILDFLAG(/' \
$(git grep -l '#ifdef BUILDFLAG('
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- gsed -i -z -E -e \
's%(.*)#include "%\1#include "build/buildflag.h"\n#include "%' \
$(git grep -l 'BUILDFLAG(IS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm')
- Spot checks to move #include "build/buildflag.h" to the correct parts
of files.
- sed -i '' -E -e \
's%^(#include "build/buildflag.h")$%#include "build/build_config.h"\n\1%' \
$(grep -L '^#include "build/build_config.h"$'
$(git grep -l 'BUILDFLAG(IS_'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'))
- Add “clang-format off” around tool usage messages.
- git cl format
- Update mini_chromium to 85ba51f98278 (intermediate step).
TESTING ONLY).
- for f in $(git grep -l '^#include "build/buildflag.h"$'
'**/*.c' '**/*.cc' '**/*.h' '**/*.m' '**/*.mm'); do \
grep -v '^#include "build/buildflag.h"$' "${f}" > /tmp/z; \
cp /tmp/z "${f}"; done
- git cl format
- Update mini_chromium to 735143774c5f (intermediate step).
- Update mini_chromium to f41420eb45fa (as checked in).
- Update mini_chromium to 6e2f204b4ae1 (as checked in).
For ease of review and inspection, each of these steps is uploaded as a
new patch set in a review series.
This includes an update of mini_chromium to 6e2f204b4ae1:
f41420eb45fa Use BUILDFLAG for OS checking
6e2f204b4ae1 Include what you use: string_util.h uses build_config.h
Bug: chromium:1234043
Change-Id: Ieef86186f094c64e59b853729737e36982f8cf69
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3400258
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Previously we would rely on implicit re-raising to deliver signals to
the underlying handler on POSIX systems if the signal is detected as
being re-raisable via WillSignalReraiseAutonomously(). This detection
mechanism is imperfect, as it will misclassify signals delivered as
a result of kill(2) when passing a signal number usually used for
synchronous signals, but now also asynchronous MTE tag check faults,
which are delivered as SIGSEGV signals on Linux. As a result, these
signals would not be re-raised and therefore would be discarded.
Although we could, for example, teach WillSignalReraiseAutonomously()
about MTE faults, the signal would still be re-raised via raise(3)
and therefore we would lose the information in siginfo.
We can avoid discarding these signals on Linux while at the
same time preserving the siginfo by making use of the syscall
rt_tgsigqueueinfo(2) which delivers a signal together with a
user-provided siginfo. The problem still exists on non-Linux POSIX
systems because this syscall is Linux-specific.
With kernel versions prior to 3.9, the kernel will reject the
rt_tgsigqueueinfo() syscall with EPERM. If that happens, follow
the non-Linux code path.
Change-Id: Ia410fbd651a756945c9402e361edfd5c520453d6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3300991
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Causes test failures on older versions of Android (e.g. Marshmallow).
Also reverts follow-up CL "Fix dead-code warning in util/posix/signals.cc".
This reverts commits ab9a87fb5463e5d1579e16bacb1f79d0dd71119b and
04431eccfe878570b1c74a5b376d96b4c9c7e0e8.
Bug: 1272877
Change-Id: Id9ef420516c932147b6c8b67d9f4daf9d31d9b03
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3300986
Reviewed-by: Peter Boström <pbos@chromium.org>
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
This unblocks a roll of crashpad into chromium.
Bug: None
Change-Id: I54fc53e0b53b8a7c7ff8e28c4657b46587bfad8d
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3287226
Commit-Queue: Peter Boström <pbos@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This pulls in "base/ignore_result.h" from mini_chromium through DEPS and
updates existing uses of "base/macros.h" to use "base/ignore_result.h".
Bug: chromium:1010217
Change-Id: I283e2bcfb2775de420d7e767b3b4a639dbba9e20
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3286105
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Previously we would rely on implicit re-raising to deliver signals to
the underlying handler on POSIX systems if the signal is detected as
being re-raisable via WillSignalReraiseAutonomously(). This detection
mechanism is imperfect, as it will misclassify signals delivered as
a result of kill(2) when passing a signal number usually used for
synchronous signals, but now also asynchronous MTE tag check faults,
which are delivered as SIGSEGV signals on Linux. As a result, these
signals would not be re-raised and therefore would be discarded.
Although we could, for example, teach WillSignalReraiseAutonomously()
about MTE faults, the signal would still be re-raised via raise(3)
and therefore we would lose the information in siginfo.
We can avoid discarding these signals on Linux while at the
same time preserving the siginfo by making use of the syscall
rt_tgsigqueueinfo(2) which delivers a signal together with a
user-provided siginfo. The problem still exists on non-Linux POSIX
systems because this syscall is Linux-specific.
Change-Id: I6df58d9371e29f75e19b4f899b723d4047f12936
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3278691
Commit-Queue: Peter Collingbourne <pcc@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The way that division operations behave have changed between Armv7
and Armv8. On the later one, divisions by zero will *not* yield an
exception of any kind (for both a 32bit and 64bit app), for hardware
integer divide operation.
On Arm processors exceptions may also be a factor of:
- if the hardware implementation supports it.
- if the kernel has set the proper internal state registers/flags.
- C library implementations (e.g. libgcc x clang_rt).
Aside that, a division by zero is within the realm of UD (Undefined
Behavior) in C/C++.
Since there are two categories of tests (explicit raise x caused by
instructions), it just makes sense to disable the second for Arm
since there is no reliable way to cause a SIGFPE without an explicit
raise() POSIX call.
For x86, we keep the previous implementation idea but streamlined
the code by deploying 'volatile' to ensure that the compiler
won't optimize away the result of the division (i.e no need
to call stat() and fstat()).
Bug: chromium:919548, chromium:1184398
Change-Id: Ib0fd4bdf503dcd50149dccae0577c777488c0238
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3213431
Commit-Queue: Adenilson Cavalcanti <cavalcantii@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This change was partially scripted and partially done manually with vim
regex + manually placing the deleted constructors.
The script change looked for destructors in the public: section of a
class, if that existed the deleted constructors would go before the
destructor.
For manual placement I looked for any constructor in the public: section
of the corresponding class. If there wasn't one, then it would ideally
have gone as the first entry except below enums, classes and typedefs.
This may not have been perfect, but is hopefully good enough. Fingers
crossed.
#include "base/macros.h" is removed from files that don't use
ignore_result, which is the only other thing defined in base/macros.h.
Bug: chromium:1010217
Change-Id: I099526255a40b1ac1264904b4ece2f3f503c9418
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3171034
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Chromium moved base::size() to base/cxx17_backports.h, so do the same in
mini_chromium and update the users in Crashpad.
Roll mini_chromium to 2f06f83f to make the new base header available.
Bug: chromium:1210983
Change-Id: Ie3dc4c189dcdfcac030b95fe285f94abb29a27bf
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2917779
Commit-Queue: Lei Zhang <thestig@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The broker attempts to use sbrk() to allocate memory to track ptrace
attachments. If the process failed due to an OOM, this system call might
fail, the broker falls back to saving attachments on the stack, and then
overruns the stack.
This change updates the broker to use sys_mmap() instead of sbrk(),
which is expected to work at least as well. If sys_mmap() fails or
the first mapped page is exhausted, further attachments fail without
attempting to save them to the stack.
Bug: chromium:1128441
Change-Id: Ibffaa986403adaf3178ee77e6d210053fbf60f26
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2488280
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
A new bug in macOS 11.0db6 20A5364e has broken the {CTL_KERN,
KERN_PROCARGS2} sysctl such that it will not work properly unless
provided with a buffer at least 17 bytes larger than originally
indicated. Work around the bug by providing a buffer a whole 32 bytes
larger.
Bug: crashpad:347, crashpad:355
Test: crashpad_util_test ProcessInfo.{Self,SelfTask,Forked}
Change-Id: I9324a63390875308979a10fefcd4c1c880651aee
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2399646
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
On x86_64, it’s impossible for a signal handler distinguish between
SIGBUS caused synchronously by a hardware fault and SIGBUS raised
asynchronously by software. This remains true on arm64, and is expanded
to include both SIGILL and SIGSEGV.
Bug: crashpad:345
Test: crashpad_util_test Signals.Raise_HandlerReraisesTo*
Change-Id: I181ea35121048dc0c666e2346340e698220ca650
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2386463
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
We're working to decouple ChromeOS and Linux builds of Chrome.
Currently OS_CHROMEOS sets OS_LINUX, so we need to refactor
current OS_LINUX usage to make this explicit.
More information can be found at go/cros_is_linux_os_linux
BUG=chromium:1110266
TEST=manual build
Change-Id: Ie765da1ab6a0bf0286538ae1df3697abaa29aeaa
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2391116
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
If the file just needs the CHECK/CHECK_OP/NOTREACHED
macros, use the appropriate header for that instead.
Or if logging.h is not needed at all, remove it.
This is both a nice cleanup (logging.h is a big header,
and including it unnecessarily has compile-time costs),
and part of the final step towards making logging.h no
longer include check.h and the others.
Bug: chromium:1031540
Change-Id: Ia46806bd95fe498bcf3cf6d2c13ffa4081678043
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2255361
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Add direct includes for things provided transitively by logging.h
(or by other headers including logging.h).
This is in preparation for cleaning up unnecessary includes of
logging.h in header files (so if something depends on logging.h,
it needs include it explicitly), and for when Chromium's logging.h
no longer includes check.h, check_op.h, and notreached.h.
DEPS is also updated to roll mini_chromium to ae14a14ab4 which
includes these new header files.
Bug: chromium:1031540
Change-Id: I36f646d0a93854989dc602d0dc7139dd7a7b8621
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2250251
Commit-Queue: Hans Wennborg <hans@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
I’m most interested in picking up 1b3eb6ef3462, “Explicitly define copy
constructors used in googletest tests.”
This also reorganizes files and rewrites text to refer to this project
as Google Test and googletest (and Google Mock and googlemock), as it
prefers to be known. Some filenames are left at gtest_* following the
precedent set by gtest itself. For example, #include "gtest/gtest.h" is
still used, so #include "test/gtest_death.h" is retained too.
gtest_all_test OutputFileHelpersTest.GetCurrentExecutableName hard-codes
the expected executable name as gtest_all_test among other options that
do not include googletest_all_test, so test executables retain their
names as well.
fb19f57880f6 Add GTEST_BRIEF option
3549237957a1 Ensure that gtest/gmock pkgconfig requirements specify
version
189299e957bb Merge branch 'master' into quiet-flag
5504ded3ab5c Fix a typo in .travis.yml
6ed4e7168f54 Replace the last instance of `throw()` with `noexcept`. NFC
879fd9b45299 Remove duplicate codes existed in get-nprocessors.sh
644f3a992c28 gtest-unittest-api_test - fix warning in clang build
0b6d567619fe Remove redundant .c_str()
be3ac45cf673 fix signed/unsigned comparison issue (on OpenBSD)
b51a49e0cb82 Merge pull request #2773 from Quuxplusone:replace-noexcept
c2032090f373 Merge pull request #2772 from Quuxplusone:travis
4fe5ac53337e Merge pull request #2756 from Conan-Kudo:fix-pkgconfig-reqs
373d72b6986f Googletest export
4c8e6a9fe1c8 Merge pull request #2810 from ptahmose:master
71d5df6c6b67 Merge pull request #2802 from e-i-n-s:fix_clang_warning
dcc92d0ab6c4 Merge pull request #2805 from pepsiman:patch-1
4f002f1e236c VariadicMatcher needs a non-defaulted move constructor for
compile-time performance
9d580ea80592 Enable protobuf printing for open-source proto messages
766ac2e1a413 Remove all uses of GTEST_DISALLOW_{MOVE_,}ASSIGN_
11b3cec177b1 Fix a -Wdeprecated warning
01c0ff5e2373 Fix a -Wdeprecated warning
c7d8ec72cc4b Fix a -Wdeprecated warning
1b066f4edfd5 Add -Wdeprecated to the build configuration
4bab55dc54b4 Removed a typo in README.md
a67701056425 Googletest export
fb5d9b66c5b0 Googletest export
1b3eb6ef3462 Googletest export
b0e53e2d64db Merge pull request #2797 from Jyun-Neng:master
d7ca9af0049e Googletest export
955552518b4e Googletest export
ef25d27d4604 Merge pull request #2815 from Quuxplusone:simple
129329787429 Googletest export
b99b421d8d68 Merge pull request #2818 from inazarenko:master
472cd8fd8b1c Merge pull request #2818 from inazarenko:master
3cfb4117f7e5 Googletest export
0eea2e9fc634 Googletest export
a9f6c1ed1401 Googletest export
1a9c3e441407 Merge pull request #2830 from keshavgbpecdelhi:patch-1
e589a3371705 Merge pull request #2751 from calumr:quiet-flag
Change-Id: Id788a27aa884ef68a21bae6c178cd456f5f6f2b0
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2186009
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
ProcStatReader.Threads is flaky because it relies on an internal,
imprecise measurement of boot time. The flaky test asserts that a
thread started after the main thread should have a start time >= the
main thread. The start time is returned in a timeval, with microsecond
precision, but the measurement of boot time requires two system calls
and the time between those system calls can be approximately a
microsecond. An unlucky event such as a change in system time could
make this imprecision arbitrarily bad.
This patch lets the caller of ProcStatReader.StartTime() inject the
boot time, allowing ProcStatReader to guarantee that threads have
correctly ordered time, given the same input boot time.
Bug: 1016765
Change-Id: I6e4a944a1d58c3916090bab6a4b99573e71a89fc
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1891588
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
9d26012e9c73 relaxed the requirement on ScopedMmap such that the length
of the region supervised no longer needed to be provided as a round
number of pages. This was accomplished by internally rounding up the
provided length to a page length. Unfortunately, this made
ScopedMmap::len() return something other than the passed-in length,
which is undesirable. This change makes ScopedMmap store the passed-in
length internally, making it available unmodified via the accessor, and
rounding it up to page length at internal points of use.
Change-Id: I827925af68e38f33bfa3cee535db0f098884fc6b
Reviewed-on: https://chromium-review.googlesource.com/c/1492774
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
ScopedMmap was asserting that the length of a mapped region must be an
exact number of pages, but this is not required or useful.
Change-Id: I6141712a1980a217565e31ddcd4c23cf6a32503c
Reviewed-on: https://chromium-review.googlesource.com/c/1480440
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This is a follow-up to c8a016b99d97, following the post-landing
discussion at
https://chromium-review.googlesource.com/c/crashpad/crashpad/+/1393921/5#message-2058541d8c4505d20a990ab7734cd758e437a5f7
base::size, and std::size that will eventually replace it when C++17 is
assured, does not allow the size of non-static data members to be taken
in constant expression context. The remaining uses of ArraySize are in:
minidump/minidump_exception_writer.cc (×1)
minidump/minidump_system_info_writer.cc (×2, also uses base::size)
snapshot/cpu_context.cc (×4, also uses base::size)
util/misc/arraysize_test.cc (×10, of course)
The first of these occurs when initializing a constexpr variable. All
others are in expressions used with static_assert.
Includes:
Update mini_chromium to 737433ebade4d446643c6c07daae02a67e8deccao
f701716d9546 Add Windows ARM64 build target to mini_chromium
87a95a3d6ac2 Remove the arraysize macro
1f7255ead1f7 Placate MSVC in areas of base::size usage
737433ebade4 Add cast
Bug: chromium:837308
Change-Id: I6a5162654461b1bdd9b7b6864d0d71a734bcde19
Reviewed-on: https://chromium-review.googlesource.com/c/1396108
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This will be useful to allow setting variables such as CLASSPATH or
LD_LIBRARY_PATH without modifying or depending upon the application's
current environment.
Bug: crashpad:30
Change-Id: I34f31bcc397e51d789b48eb654d80f992a719074
Reviewed-on: https://chromium-review.googlesource.com/1194399
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
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>
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>
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>
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>
1) Add PtraceConnection which serves as the base class for specific
types of connections Crashpad uses to trace processes.
2) Add DirectPtraceConnection which is used when the handler process
has `ptrace` capabilities for the target process.
3) Move `ptrace` logic into Ptracer. This class isolates `ptrace` call
logic for use by various PtraceConnection implementations.
Bug: crashpad:30
Change-Id: I98083134a9f7d9f085e4cc816d2b85ffd6d73162
Reviewed-on: https://chromium-review.googlesource.com/671659
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
This is essentially based on a search for “^ *const [^*&]*=[^(]*$”
Change-Id: Id571119d0b9a64c6f387eccd51cea7c9eb530e13
Reviewed-on: https://chromium-review.googlesource.com/585555
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
This uses “static” at function scope to avoid making local copies, even
in cases where the compiler can’t see that the local copy is
unnecessary. “constexpr” adds additional safety in that it prevents
global state from being initialized from any runtime dependencies, which
would be undesirable.
At namespace scope, “constexpr” is also used where appropriate.
For the most part, this was a mechanical transformation for things
matching '(^| )const [^=]*\['.
Similar transformations could be applied to non-arrays in some cases,
but there’s limited practical impact in most non-array cases relative to
arrays, there are far more use sites, and much more manual intervention
would be required.
Change-Id: I3513b739ee8b0be026f8285475cddc5f9cc81152
Reviewed-on: https://chromium-review.googlesource.com/583997
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Leonard Mosescu <mosescu@chromium.org>
ThreadInfo provides a uniform interface to collect register sets or
the thread-local storage address across bitness for x86 and ARM family
architectures. Additionally, ThreadInfo.h defines context structs which
mirror those provided in sys/user.h. This allows tracing across bitness
as the structs in sys/user.h are only provided for a single target
architecture.
Bug: crashpad:30
Change-Id: I91d0d788927bdac5fb630a6ad3c6ea6d3645ef8a
Reviewed-on: https://chromium-review.googlesource.com/494075
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
syscall(0) results in SIGSYS on x86_64, but not 32-bit x86. Choose a
high number as a nonexistent syscall number. As of 10.12.4, the highest
known system call number is 521.
Test: crashpad_util_test Signals.Cause*
Change-Id: I82dbd210f0c90fe933898ea0d360b431b10d090e
Reviewed-on: https://chromium-review.googlesource.com/489826
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Some of the new Linux/Android tests were failing in 32-bit code where
pointers were being casted via reinterpret_cast<>() to LinuxVMAddress,
an unsigned 64-bit type. The behavior of such casts is
implementation-defined, and in this case, sign-extension was being used
to convert the 32-bit pointers to 64 bits, resulting in very large
(unsigned) LinuxVMAddress values that could not possibly refer to proper
addresses in a 32-bit process’ address space.
The offending reinterpret_cast<>() conversions have been replaced with
the new FromPointerCast<>(), which is careful to do sign-extension when
converting to a signed type, and zero-extension when converting to an
unsigned type like LinuxVMAddress.
Bug: crashpad:30
Test: crashpad_util_test FromPointerCast*:MemoryMap.*:ProcessMemory.*
Change-Id: I6f1408dc63369a8740ecd6015d657e4407a7c271
Reviewed-on: https://chromium-review.googlesource.com/488264
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The Groups: line unfortunately always had a trailing space, but Linux
4.10 takes this to a new level by including a trailing space even when
no groups are present. See commit f7a5f132b447,
linux-4.10.10/fs/proc/array.c task_state().
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.Pid1
Change-Id: If498abd929b27c7f28b69144e7c4928b1626acdb
Reviewed-on: https://chromium-review.googlesource.com/477070
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
gtest used to require (expected, actual) ordering for arguments to
EXPECT_EQ and ASSERT_EQ, and in failed test assertions would identify
each side as “expected” or “actual.” Tests in Crashpad adhered to this
traditional ordering. After a gtest change in February 2016, it is now
agnostic with respect to the order of these arguments.
This change mechanically updates all uses of these macros to (actual,
expected) by reversing them. This provides consistency with our use of
the logging CHECK_EQ and DCHECK_EQ macros, and makes for better
readability by ordinary native speakers. The rough (but working!)
conversion tool is
https://chromium-review.googlesource.com/c/466727/1/rewrite_expectassert_eq.py,
and “git cl format” cleaned up its output.
EXPECT_NE and ASSERT_NE never had a preferred ordering. gtest never made
a judgment that one side or the other needed to provide an “unexpected”
value. Consequently, some code used (unexpected, actual) while other
code used (actual, unexpected). For consistency with the new EXPECT_EQ
and ASSERT_EQ usage, as well as consistency with CHECK_NE and DCHECK_NE,
this change also updates these use sites to (actual, unexpected) where
one side can be called “unexpected” as, for example, std::string::npos
can be. Unfortunately, this portion was a manual conversion.
References:
https://github.com/google/googletest/blob/master/googletest/docs/Primer.md#binary-comparison77d6b17338https://github.com/google/googletest/pull/713
Change-Id: I978fef7c94183b8b1ef63f12f5ab4d6693626be3
Reviewed-on: https://chromium-review.googlesource.com/466727
Reviewed-by: Scott Graham <scottmg@chromium.org>
This also enhances ScopedMmapDeathTest.Mprotect to better ensure that
ScopedMmap::Mprotect() works properly.
Bug: crashpad:30
Test: crashpad_util_test ScopedMmap*.*
Change-Id: Iff35dba9fa993086f3f4cd8f4a862d802e637bb1
Reviewed-on: https://chromium-review.googlesource.com/464547
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
It should be possible to shrink a region already supervised by
ScopedMmap, or in rare cases when ScopedMmap is supervising only a
smaller portion of an overall larger region, increase the size of the
region it supervises. This is now equivalent to the operation of
base::mac::ScopedMachVM::reset().
The Reset() and ResetAddrLen() methods are upgraded from a void return
to a bool return to indicate their success.
Bug: crashpad:30
Test: crashpad_util_test ScopedMmap*.ResetAddrLen_*
Change-Id: I564e154cd2387e8df3f83b416ecc1c83c9bcf71d
Reviewed-on: https://chromium-review.googlesource.com/464286
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Use test::Multiprocess, which ensures that waitpid() is called to reap
child processes.
Previously, after a several thousand iterations (using --gtest_repeat),
fork() would begin failing with EAGAIN:
[ RUN ] ProcessInfo.Forked
../../util/posix/process_info_test.cc:165: Failure
Expected: (pid) >= (0), actual: -1 vs 0
fork: Resource temporarily unavailable (35)
[ FAILED ] ProcessInfo.Forked (0 ms)
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.Forked
Change-Id: Ia95c9297d5eeb02894f58844ced1b50981870cbc
Reviewed-on: https://chromium-review.googlesource.com/461482
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
NDK r13 and earlier provided a bogus definition of OPEN_MAX, but it was
removed from NDK r14 effective in a future API level. It is also not
available when using a standalone toolchain with unified headers.
ff5f17bc8a
Bug: crashpad:30
Change-Id: Ic89d6879cb1a4e5b9d20e9cb06bedd5176df0f2a
Reviewed-on: https://chromium-review.googlesource.com/458121
Reviewed-by: Scott Graham <scottmg@chromium.org>
Previously on macOS, the test used an OS-specific library function to
recover the original argc and argv. On Linux/Android, it essentially
reimplemented the very code it was testing, which didn’t make for a very
good test. The new approach is to save argc and argv in main() and base
the comparison on that.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*, crashpad_test_test MainArguments.*
Change-Id: I578abed3b04ae10a22f79a193bbb8b6589276c97
Reviewed-on: https://chromium-review.googlesource.com/456798
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This implements a non-stdio-based getline() equivalent. getline() is not
in the Android NDK until API 21 (Android 5.0.0), while Chrome builds for
32-bit platforms with API 16 (Android 4.1.0). Although a getline()
declaration could be provided in compat for use with older NDK headers,
it’s desirable to move away from stdio entirely. The C++
DelimitedFileReader interface is also a bit more comfortable to use than
getline().
A getdelim() equivalent is also provided, and is also used in the
Linux/Android ProcessInfo implementation.
Bug: crashpad:30
Test: crashpad_util_test FileLineReader.*:ProcessInfo.*
Change-Id: Ic1664758a87cfe4953ab22bd3ae190761404b22c
Reviewed-on: https://chromium-review.googlesource.com/455998
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
The PTRACE_GETREGSET ptrace() request is not supported on ARM before
Linux 3.5.0. This request was only used to determine the bitness of the
target process. Since 64-bit ARM is only supported as of Linux 3.7.0,
when this request is not supported on 32-bit ARM, 64-bit is also not
supported, and the target process must be a 32-bit process.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: Ib004d24858f146df898dfa6796926d97e2510541
Reviewed-on: https://chromium-review.googlesource.com/455398
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Not all libc implementations reliably expose pt_regs from
<sys/ptrace.h>. glibc-2.25/sysdeps/generic/sys/ptrace.h, for example,
does not #include <asm/ptrace.h> (which defines the structure) or
anything else that would #include that file such as <linux/ptrace.h>. On
the other hand, Android 7.1.1 bionic/libc/include/sys/ptrace.h does
#include <linux/ptrace.h>.
It is not viable to #include <asm/ptrace.h> or <linux/ptrace.h>
directly: it would be natural to #include them, sorted, before
<sys/ptrace.h> but this causes problems for glibc’s <sys/ptrace.h>.
Constants like PTRACE_GETREGS and PTRACE_TRACEME are simple macros in
<asm/ptrace.h> and <linux/ptrace.h>, respectively, but are defined in
enums in glibc’s <sys/ptrace.h>, and this doesn’t mix well. It is
possible to #include <asm/ptrace.h> (but not <linux/ptrace.h>) after
<sys/ptrace.h>, but because this involves same-value macro redefinitions
and because it reaches into internal headers, it’s not preferred.
The alternative approach taken here is to use the user_regs structure
from <sys/user.h>, which is reliably defined by both Bionic and glibc,
and has the same layout as the kernel’s pt_regs structure. (All that
matters in this code is the size of the structure.) See Android 7.1.1
bionic/libc/include/sys/user.h,
glibc-2.25/sysdeps/unix/sysv/linux/arm/sys/user.h, and
linux-4.9.15/arch/arm/include/asm/ptrace.h for the various equivalent
definitions.
Take the same approach for 64-bit ARM: use user_regs_struct from
<sys/user.h> in preference to hoping for a C library’s <sys/ptrace.h> to
somehow provide the kernel’s user_pt_regs.
This mirrors the approach already being used for x86 and x86_64, which
use the C library’s <sys/user.h> user_regs_struct.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: I3067e32c7fa4d6c8f4f2d5b63df141a0f490cd13
Reviewed-on: https://chromium-review.googlesource.com/455558
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Lazy initialization is particularly beneficial for Is64Bit(), which uses
a different (ptrace()-based) approach than the rest of the class (which
is /proc-based). It is possible for the /proc-based Initialize() to
succeed while ptrace() would fail, as it typically would in the
ProcessInfo.Pid1 test. Because this test does not call Is64Bit(),
permission to ptrace() shouldn’t be necessary, and in fact ptrace()
shouldn’t even be called.
This enables the ProcessInfo.Pid1 test on Android (due to ptrace(), it
was actually failing on any Linux, not just Android). It also enables
the ProcessInfo.Forked test on non-Linux, as the prctl(PR_SET_DUMPABLE)
Linux-ism can be removed from it.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: Ic883733a6aed7e7de9a0f070a5a3544126c7e976
Reviewed-on: https://chromium-review.googlesource.com/455656
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
The process start time in ticks was being converted to an integer from a
temporary string that had gone out of scope by the time the conversion
was performed.
It was possible for a format error in /proc/pid/stat to go undetected
and result in a buffer overflow.
Bug: crashpad:30
Change-Id: I03566dda797bc1f23543bfffcfdb2c5ffe1eca66
Reviewed-on: https://chromium-review.googlesource.com/455378
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This configuration uses user_regs_struct, which is declared in
<sys/user.h>.
Bug: crashpad:30
Change-Id: Ibdcc60c6719fc2bad9fbeef116efbe764229e14b
Reviewed-on: https://chromium-review.googlesource.com/455197
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Use these utilities for signal handling in crashpad_handler
BUG=crashpad:30
TEST=crashpad_util_test Signals.*
Change-Id: I6c9a1de35c4a81b58d77768c4753bdba5ebea4df
Reviewed-on: https://chromium-review.googlesource.com/446917
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Includes an update of mini_chromium to 3a2d52d74c9a:
3a2d52d74c9a Use O_CLOEXEC (and O_NOCTTY) when calling open()
BUG=chromium:688362
Change-Id: I2bdf86efe4e6559ecb77492ac5bdc728aa035889
Reviewed-on: https://chromium-review.googlesource.com/447999
Reviewed-by: Scott Graham <scottmg@chromium.org>
Use “macOS” as the generic unversioned name of the operating system in
comments. For version-specific references, use Mac OS X through 10.6, OS
X from 10.7 through 10.11, and macOS for 10.12.
Change-Id: I1ebee64fbf79200bc799d4a351725dd73257b54d
Reviewed-on: https://chromium-review.googlesource.com/408269
Reviewed-by: Robert Sesek <rsesek@chromium.org>
- In the ProcessInfo test, port the global argc/argv getter to Linux by
reading /proc/self/cmdline.
- Use <inttypes.h> format macros for 64-bit types.
- Only #include <sys/sysctl.h> on macOS.
- #include <signal.h> instead of <sys/signal.h>.
In order to test on Linux/Android, the following changes to the
crashpad_util_test target must be made until more porting is complete:
- Remove the dependency on crashpad_client because that library has not
been ported yet.
- Remove process_info_test.cc because it depends on crashpad_client and
there is no implementation of ProcessInfo for Linux yet.
- Remove http_transport_test.cc because there is no HTTPTransport
implementation for Linux or Android yet.
- Remove checked_address_range_test.cc because checked_address_range.cc
does not yet expose a cross-bit usable type for addresses and sizes
on Linux.
BUG=crashpad:30
TEST=crashpad_util_test
Change-Id: Ic17cf26bdf19b3eff3915bb1acdaa701f28222cd
Reviewed-on: https://chromium-review.googlesource.com/405647
Reviewed-by: Robert Sesek <rsesek@chromium.org>
With this change, it is possible to build crashpad_util for Android with
clang. I built with NDK 13b (clang 3.8) at API 24 (current), API 21
(used by Chrome in 64-bit builds), and API 16 (used by Chrome in 32-bit
builds).
- In WeakFileHandleFileWriter::WriteIoVec(): Android does not expose
the IOV_MAX macro, but its value can be obtained by calling
sysconf(_SC_IOV_MAX).
- In CloseMultipleNowOrOnExec(): API 21 removes getdtablesize(). Skip
it, because it returned the same thing as sysconf(_SC_OPEN_MAX),
which is already consulted.
- Throughout: Various #ifdefs checking for OS_LINUX have been extended
to also check for OS_ANDROID. In Chrome’s build_config.h (and thus
mini_chromium’s), OS_LINUX is not defined when OS_ANDROID is.
This has not been tested beyond building the crashpad_util target.
BUG=crashpad:30
Change-Id: Ieb0bed736029d2d776c534e30e534f186e6fb663
Reviewed-on: https://chromium-review.googlesource.com/405267
Reviewed-by: Robert Sesek <rsesek@chromium.org>
With this change, it is possible to build crashpad_util on Linux. I
built with clang 3.8.1 and GCC 6.2.0.
- For per-OS “exception code” metrics, Android and Linux are broken out
distinctly.
- Because Linux provides no standard UUID generator, base::RandBytes()
is used to generate random UUIDs for the InitializeWithNew() form.
- Multiple fixes for CloseMultipleNowOrOnExec():
- readdir_r() is deprecated in glibc 2.24. Use readdir() on Linux.
- Linux does not have OPEN_MAX. Use the fs.nr_open sysctl (via
/proc/sys) to determine the maximum (currently-configured)
possible number of file descriptors per process.
- Use the {CTL_KERN, KERN_MAXFILESPERPROC} sysctl on Mac to
determine the maximum (currently-configured) possible number of
file descriptors per process. This is an improvement over using
OPEN_MAX, which is still consulted.
- ThreadLogMessages’ use of DCHECK_EQ() needs an address-of operator on
function pointers to avoid confusing GCC.
One problem remains:
- util/misc/pdb_structures.h produces -Wmultichar errors. -Wmultichar
is enabled by default with GCC (but not clang). It is impossible to
disable this warning with #pragma GCC diagnostic ignored. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
This has not been tested beyond building the crashpad_util target.
BUG=crashpad:30
Change-Id: I02e7a05da512ca312806d825b3fc9b2c5bf1a990
Reviewed-on: https://chromium-review.googlesource.com/404009
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This was done in Chromium’s local copy of Crashpad in 562827afb599. This
change is similar to that one, except more care was taken to avoid
including headers from a .cc or _test.cc when already included by the
associated .h. Rather than using <stddef.h> for size_t, Crashpad has
always used <sys/types.h>, so that’s used here as well.
This updates mini_chromium to 8a2363f486e3a0dc562a68884832d06d28d38dcc,
which removes base/basictypes.h.
e128dcf10122 Remove base/move.h; use std::move() instead of Pass()
8a2363f486e3 Move basictypes.h to macros.h
R=avi@chromium.org
Review URL: https://codereview.chromium.org/1566713002 .
After 9e79ea1da719, it no longer makes sense for crashpad_util_test_lib
to “hide” in util/util_test.gyp. All of util/test is moved to its own
top-level directory, test, which all other test code is allowed to
depend on. test, too, is allowed to depend on all other non-test code.
In a future change, when crashpad_util_test_lib gains a dependency on
crashpad_client, it won’t look so weird for something in util (even
though it’s in util/test) to depend on something in client, because the
thing that needs to depend on client will live in test, not util.
BUG=crashpad:33
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1051533002
This function will be useful in upcoming non-test code. Because the
first Crashpad client that wants a Crashpad handler will now be
responsible for starting the handler process, this will prevent file
descriptors from leaking to the handler process.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/819483002
There will be no reason to leave the handler process connected to its
invoker’s stdin or stdout.
On the other hand, I’m currently leaving it connected to the original
and stderr, as these may be useful for diagnostics.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/818573002
This DCHECK fails for me locally as
[----------] 3 tests from ProcessInfo
[ RUN ] ProcessInfo.Self
[70989:10546846:20141216,112509.948519:FATAL process_info_mac.cc:114] Check failed: static_cast<size_t>(ngroups) < (sizeof(ArraySizeHelper(kern_proc_info_.kp_eproc.e_ucred.cr_groups))) (16 vs. 16).
Abort trap: 6
It doesn't seem to happen on the waterfall, so maybe I'm building against
an incorrect header? I don't particularly understand the code, but assuming
it's normal 0-based array, perhaps it should be a DCHECK_LE in any case.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/813473002
DropPrivileges() is used in exception_port_tool, so that when it is
installed as a setuid executable, it only uses elevated privileges to
obtain a task port for its -p option, and then relinquishes those
privileges.
It is difficult to provide a test for this function, because it must be
running setuid or setgid in order to do anything interesting. However,
the function contains its own CHECKs to verify that it behaves properly.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/727053002
Also, move ProcessArgumentsForPID() into ProcessInfo.
This change prepares for a TaskForPID() implementation that’s capable of
operating correctly in a setuid root executable. TaskForPID() belongs in
util/mach, but for its permission checks, it must access some process
properties that were previously fetched by ProcessReader in snapshot.
util can’t depend on snapshot. The generic util-safe process information
bits (Is64Bit(), ProcessID(), ParentProcessID(), and StartTime()) are
moved from ProcessReader to ProcessInfo (in util), where the current
ProcessReader can use it (as it’s OK for snapshot to depend on util),
and the future TaskForPID() in util can also use it. ProcessInfo also
contains other methods that TaskForPID() will use, providing access to
the credentials that the target process holds. ProcessArgumentsForPID()
is related, and is also now a part of ProcessInfo.
TEST=snapshot_test, util_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/727973002
implicit_cast<> only performs a cast in cases where an implicit
conversion would be possible. It’s even safer than static_cast<> It’s an
“explicit implicit” cast, which is not normally necsesary, but is
frequently required when working with the ?: operator, functions like
std::min() and std::max(), and logging and testing macros.
The public style guide does not mention implicit_cast<> only because it
is not part of the standard library, but would otherwise require it in
these situations. Since base does provide implicit_cast<>, it should be
used whenever possible.
The only uses of static_cast<> not converted to implicit_cast<> are
those that require static_cast<>, such as those that assign an integer
constant to a variable of an enum type.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/700383007
This change was generated mechanically by running:
find . \( -name \*.cc -or -name \*.mm -or -name \*.h \) \
-and -not -path ./third_party/\* -and -not -path ./out/\* \
-exec sed -i '' -E -e 's/(^|[^_])NULL/\1nullptr/g' {} +
Further manual fix-ups were applied to remove casts of nullptr to other
pointer types where possible, to preserve the intentional use of NULL
(as a short form of MACH_PORT_NULL) in exception_port_tool, and to fix
80-column violations.
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/4mijeJHzxLg/discussion
TEST=*_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/656703002
