Included are additional automated edits by clang-format on import.
Merge d74896699f into 22091f4c0d
Merging this change closes#1500
COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1500 from ryandesign:MAP_ANONYMOUS d74896699f
PiperOrigin-RevId: 552922776
Change-Id: I96a0395cb5e7156d7c7a889491c5d0b4cf755819
Don't assume that function ptr == PC. Adds a redirection mechanism, GetPCFromFnPtr, and enables more test cases for Emscripten/Wasm.
On many (most?) platforms, the address of a function ptr is the same as its
Program Counter (PC) for the purpose of most things, including symbolization.
In Emscripten WebAssembly, the function ptr is just an index into a table of
functions. However, the name section maps function names to their literal
offsets into a Wasm binary. The WasmOffsetConverter is actually capable of both
indirections, so we can effectively go from function ptr to offset into the
binary (which is typically the "PC" for other Stack dumping things in Wasm,
including `emscripten_pc_get_function`).
More info: https://www.w3.org/TR/wasm-js-api-2/#exported-function-exotic-objects
Also fix Emscripten symbolize handling for `nullptr` now that we have tests for
that.
PiperOrigin-RevId: 546006678
Change-Id: I0d4015ca9035b004158451b36c933cad009184ba
The big-endian PowerPC ELF ABI (ppc64 in Debian) relies on function
descriptors mapped in a non-executable segment. Make sure that segment
is scanned during symbolization. Also correct bounds computation for
that segment.
PiperOrigin-RevId: 544440302
Change-Id: Ic05532aa35ae9efa127028318640ee7cdeeecc5f
which makes it give up in certain situations where the x86 handler works
fine
This change adopts x86's more sophisticated stack-bounds-checking
method for aarch64, and enables the HugeStack test to pass on aarch64.
PiperOrigin-RevId: 540655431
Change-Id: If7d816330327722bbe5c135abfa77fda5e7e452b
It no longer strictly writes to stderr, since Emscripten/WebAssembly now use _emscripten_err which might be replaced by something that is not the same as stderr by the host.
PiperOrigin-RevId: 540655336
Change-Id: Icc2a430a0db53a1282ef5558e9f3648db67e972c
This fixes an endless loop in the absl Arm stack unwinder where encountering a
second signal return trampoline (as one has in nested signal frames), would restart
unwinding at the outermost signal, resulting in an endless loop.
This does not change any behavior in the non-nested signal case, so I believe
it is safe for any stack that hasn't encountered this bug already.
I would love to test this beyond the absl unwinding test cases and the
fingerprint_test included here, but I'm at a loss for other test cases.
PiperOrigin-RevId: 539113007
Change-Id: I10037f9fa77b45cc4db61f89b9c6380ec3529113
The non-RAW_ versions provide better output but weren't available when most of these tests were written.
There are just a couple spots where RAW_ is actually needed, e.g. signal handlers and malloc hooks.
Also fix a couple warnings in layout_test.cc newly surfaced because the optimizer understands CHECK_XX differently than INTERNAL_CHECK.
PiperOrigin-RevId: 534584435
Change-Id: I8d36fa809ffdaae5a3813064bd602cb8611c1613
Use Linux's prctl(PR_SET_VMA) system call to name memory arenas being
allocated using mmap(MAP_ANONYMOUS).
This change allows Abseil's memory arena(s) to be distinguished from
other uses of anonymous memory within a process, which in turn helps
investigations into the memory usage of applications.
The change adds a new prctl() system call to the code paths that call
mmap(). This is not expected to add significant overhead to applications.
The call to prctl(PR_SET_VMA, ...) can fail if the Linux kernel in use was
not configured with the CONFIG_ANON_VMA_NAME kernel option. This should
be OK since the naming memory regions is primarily a debugging aid.
PiperOrigin-RevId: 523687348
Change-Id: Ie404e5eeef0a6da53330b3a56149c4f3bc6bf5c7
For function N in the stack, the current code reports the size of
frame N - 1. Fix that.
PiperOrigin-RevId: 520688072
Change-Id: I984729f72f79aebae1b6997cb51d3ddef9199d1e
Both e_shentsize and e_shstrndx are uint16, so the product
elf_header.e_shentsize * elf_header.e_shstrndx
can overflow the promoted type int (MAX_UINT16 * MAX_UINT16 > MAX_INT),
which is undefined behavior. Not sure if it can affect any real cases
or not, though.
Cast e_shentsize to loff_t instead of e_shoff.
This makes both multiplication and addition to use loff_t type.
PiperOrigin-RevId: 511254775
Change-Id: I39c493bfb539cca6742aae807c50718d31e7c001
On some glibcs, this is defined as a call to sysconf(), which returns a long.
PiperOrigin-RevId: 505380003
Change-Id: I53207846d733d3a529630a6aff9bca425cf90a21
Ensure that we know both real low and high stack bounds
when relying on the stack bounds check.
PiperOrigin-RevId: 504003431
Change-Id: I8f6e6b75f5edff233d3cf80285f81b53f9080a0f
END_PUBLIC
absl: relax frame size check in x86 stack unwinding
Currently the unwinder stops whenever it sees a frame >100000 bytes.
There may be such legitimate frames, the default stack size is O(megabytes).
Only do this check if we are not within the thread stack bounds.
The thread stack is assumed to be readable, so the worst thing that can happen
if the large stack frame is actually bogus is that we will add one/few wrong frames and stop.
PiperOrigin-RevId: 503374764
Change-Id: Icabb55d6468b12a42bf026c37c98dbe84977e659
deprecation of ATOMIC_FLAG_INIT.
Another option would have been to use macros to only initialize
std::atomic_flag before C++20, but I decided to use one compilation
path instead.
The major difference between std::atomic_flag and std::atomic<bool> is
that the former is guaranteed to be lock-free, but we already assume
std::atomic<bool> is lock-free in many places.
https://en.cppreference.com/w/cpp/atomic/atomic_flag
PiperOrigin-RevId: 487397075
Change-Id: I3f1c539ec8b2ca58547282e69ed73e93243e8efe
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL enables these warnings and fixes the remaining known issues.)
Bug: chromium:1292951
PiperOrigin-RevId: 480981210
Change-Id: I92d5023c6833e24d6aa29b10d433116329972f41
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on miscellaneous non-test source files.)
Bug: chromium:1292951
PiperOrigin-RevId: 473054605
Change-Id: Ifd7b24966613ca915511a3a607095508068200b8
internal/stacktrace_x86-inl.inc includes internal/raw_logging.h and therefore needs
a direct dependency to satisfy Bazel layering_check (Clang -fmodules-strict-decluse).
Clang before https://reviews.llvm.org/D132779 does not report the issue becasue:
* internal/stacktrace_x86-inl.inc is an .inc file and is not checked as a main file
* internal/stacktrace_x86-inl.inc is a textual header and older Clang incorrectly
considers there is no requesting module and suppresses the error.
PiperOrigin-RevId: 472795469
Change-Id: Ia4ad667ea80b2590cef1adfd22af025c8df826ac
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in debugging/internal/.)
Bug: chromium:1292951
PiperOrigin-RevId: 470812243
Change-Id: I5578030bb42ba73cb83d4df84f89e431ceac8992
In the case that we are unwinding with context, if the retreived frame pointer
matches the signal context, assume that the value is valid and do not perform
confidence checks. In any other case, continue to perform some validation to
avoid returning an incorrect frame pointer.
Given that the VDSO path is currently untested, remove the code to simplify the
logic in the frame walking.
PiperOrigin-RevId: 465360612
Change-Id: Iac656012182a12814bafecf20225ba68b90b4db1
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .cc files in dirs a-h.)
Bug: chromium:1292951
PiperOrigin-RevId: 464541951
Change-Id: If23b63ccea8e9b730159ff1c7288e9300a40b6bd
The changes in d6f96eda14 enabled handling cases
where the stack may be non-contiguous or not fully symbolicated (e.g. in cases
of alternate signal stacks). However, it did not properly honour the requests
from the caller to perform a strict unwinding where such frames are terminated
upon the discontinuity. This repairs that condition.
Hoist the alignment check since that is safe to perform early.
PiperOrigin-RevId: 464160529
Change-Id: Ic65645928ec60c2a3b4844f3abd4fed1b991edab
Addresses failures with the following, in some files:
-Wshorten-64-to-32
-Wimplicit-int-conversion
-Wsign-compare
-Wsign-conversion
-Wtautological-unsigned-zero-compare
(This specific CL focuses on .h and win32 .inc files.)
Bug: chromium:1292951
PiperOrigin-RevId: 463835431
Change-Id: If8e5f7f651d5cd96035e23e4623bdb08a7fedabe
The frame pointer sanity check in NextStackFrame() was more restrictive than it is necessary. The frame pointer is used to load the saved link-register and the address for the next stack frame. So it only needs to be 8-byte aligned. The aarch64 ABI does not specify an alignment requirement for the frame point.
PiperOrigin-RevId: 463368519
Change-Id: I473e05181603288f14734fe29013900c7505e201
POSIX is unclear what state a file descriptor is in after a signal is delivered in the middle of close. On Linux, the file is closed even if it returns -1 with errno=EINTR.
As such, do not use errno at all when closing files.
PiperOrigin-RevId: 462638735
Change-Id: Ie73da1f3c83b1099bef146e1ea32e9a4818597cf
In some places, we check if the amount we read is a multiple of some amount we are interested in. However, ReadFromOffset returns -1 when it errors. Certain record sizes can cause ReadFromOffset to cause us to think that we succeeded when we did not.
It also results in confusing messages in logs.
PiperOrigin-RevId: 461798762
Change-Id: I8c9c7f2cea4d1789e95e50833d5405239a47f02e
Add a hook to permit checking whether an address is in bounds for the stack.
PiperOrigin-RevId: 460997074
Change-Id: Ib3b4d0cf656e614aa083457abb079c40ef8db0ff
