`dlsym` on Android KitKat (4.4.*) raises SIGFPE when searching for
non-existent symbols. This wrapper installs a signal handler prior to
calling `dlsym`.
Bug: crashpad:30
Change-Id: Iee94672d3c11b1fad1b01526eea7df688c0356cb
Reviewed-on: https://chromium-review.googlesource.com/835411
Commit-Queue: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Although API 21 introduced support for 64-bit off_t in many system calls
or their wrappers, <stdio.h> support for 64-bit off_t is absent until
API 24.
This is a partial revert of 5969d6b1eb22, because with this more
targeted fix applying only to gtest, the rest of Crashpad will work with
a 64-bit off_t even at API levels lacking NDK support by going through
the mmap() shim in compat.
This includes a mini_chromium update to 96e32dd499a4.
85cbec19ffc0 fuchsia: Make EINTR macros no-ops
fbf410cd4d40 fuchsia: Use koid instead of getpid() for process field in
logging
96e32dd499a4 Revert "android: Don’t use _FILE_OFFSET_BITS=64 until API
21"
Bug: crashpad:211
Change-Id: I34c3c8b42eb315605e6775962b44c3c4573b7462
Reviewed-on: https://chromium-review.googlesource.com/811204
Commit-Queue: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This updates build/gyp_crashpad_android.py to define the
android_api_level GYP variable whenver unified headers are in use.
Previously, it was only set when compiling with GCC and using unified
headers. This pairs with https://crrev.com/c/804574 to allow proper
detection of when _FILE_OFFSET_BITS=64 would be inappropriate.
Since there’s no longer any possibility of using a 64-bit off_t with API
< 21, this also drops the compatibility wrapper for mmap() that allowed
this configuration to work. Too bad, I liked this, but it’s pointless to
carry now.
The development documentation is also updated to refer to NDK r16.
mini_chromium is updated to 88e056258a01450b07414642fa5fb98493c1f6ce.
f609089390cd fuchsia: Add ZX_LOG, et al. to mini_chromium
0a8c5de30c67 fuchsia: Fix RandBytes() ZX_CHECK message string
88e056258a01 android: Don’t use _FILE_OFFSET_BITS=64 until API 21
Change-Id: I932116e0c01bcddd5719f9091a070d504eae600f
Reviewed-on: https://chromium-review.googlesource.com/804555
Commit-Queue: Mark Mentovai <mark@chromium.org>
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>
ProcessReader is responsible for collecting information needed to build
a snapshot of the target process, independent of the Snapshot
interface. This CL includes implementation and tests for collecting
thread information, but does not yet collect module information.
Bug: crashpad:30
Change-Id: I911f155c953129a5fa8c031e923c0de2bd740ce0
Reviewed-on: https://chromium-review.googlesource.com/488162
Reviewed-by: Mark Mentovai <mark@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>
When Yama is enabled and /proc/sys/kernel/yama/ptrace_scope is set to 1
(YAMA_SCOPE_RELATIONAL), for a child to ptrace() its parent, the parent
must first call prctl(PR_SET_PTRACER, child_pid, ...).
Bug: crashpad:30
Test: crashpad_util_test ScopedPtraceAttach.*
Change-Id: Ic85e8551259f17f372b2362887e7701b833b4cb4
Reviewed-on: https://chromium-review.googlesource.com/472006
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The new Linux ProcessInfo implementation uses two macros not readily
available in NDK API versions older than 21 (Android 5.0.0): NT_PRSTATUS
and PR_GETREGSET.
Chrome uses API 21 for 64-bit builds, but uses API 16 for 32-bit builds.
NT_PRSTATUS is normally defined by <elf.h> or by <linux/elf.h>, included
by <elf.h>. Although the definition in <linux/elf.h> is available in
older NDK API versions, this internal header does not mix well with
<elf.h> unless <elf.h> contemplates this combination. As of NDK API 21,
<elf.h> actually delegates most of its work to <linux/elf.h>.
PR_GETREGSET is not available in the NDK at all until API 21. Its
definition is in <linux/ptrace.h>. Most user code should #include
<sys/ptrace.h> instead, which includes <linux/ptrace.h>.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: I4d07a9964db4665a49bde490e905ae9126880bc5
Reviewed-on: https://chromium-review.googlesource.com/455659
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
