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>
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>
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>
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>
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
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
