| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Included are additional automated edits by clang-format on import.
Merge d74896699faacc4a1667603e52e72cbdc8006cf6 into 22091f4c0d6626b3ef40446ce3d4ccab19425ca3
Merging this change closes #1500
COPYBARA_INTEGRATE_REVIEW=https://github.com/abseil/abseil-cpp/pull/1500 from ryandesign:MAP_ANONYMOUS d74896699faacc4a1667603e52e72cbdc8006cf6
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
|
|
|
|
|
| |
PiperOrigin-RevId: 544438364
Change-Id: I22d461f2d0aa8638a0e640eebecdc7e5e2b49ea3
|
|
|
|
|
|
|
| |
Fixes #1482
PiperOrigin-RevId: 542023050
Change-Id: Iba712083edc9a24732a71f51be22ea970115809c
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
of it into a lambda.
PiperOrigin-RevId: 535245982
Change-Id: I816f60c8b6476536df6836500f01c9a3ad88ddd4
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 534619764
Change-Id: Ied99569176766f9708d5504eac9c7024cdcfd64b
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
in some of the
builds.
PiperOrigin-RevId: 530308301
Change-Id: I7c885156e14d9c8c444c7c6f8d38e7aaac7c01a7
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 512974770
Change-Id: If7a8128996d2a73ac566faaa676ddd3858d51af6
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 511696041
Change-Id: I77a87c8721f64e0d9e9a70e08a7127312488ff21
|
| |
| |
| |
| | |
nullptr instead of 0 and nothing instead of void for function arguments is preferred.
|
|\ \
| | |
| | |
| | |
| | | |
PiperOrigin-RevId: 511271203
Change-Id: I1ed352e06265b705b62d401a50b4699d01f7f1d7
|
| |/
| |
| |
| | |
These make the changed constructors match closer to the other ones that are default.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
conversion.
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
|
|
|
|
|
| |
PiperOrigin-RevId: 498048994
Change-Id: Iee969b9171921e3ffdca2610f9b93b53678d0b9d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
This corrects the generated .pc files, so these libs match the other libs
already included there.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
PiperOrigin-RevId: 474043469
Change-Id: I9ea33a8bf026263c9e10d2a183014a5ee8df1306
|
|
|
|
|
| |
PiperOrigin-RevId: 474017481
Change-Id: I1be222fa38ad01f6ddbcddd610f9629fd4888777
|
|
|
|
|
| |
PiperOrigin-RevId: 473088472
Change-Id: If4fb8354490821cbaf53743f51bf0b0d2ba85895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Fixes #1275
PiperOrigin-RevId: 472990940
Change-Id: I1251b01b09e6a9baac52ae4df443714432115e90
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 d6f96eda14aca77748a439f05a567a46ce87e462 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
|
|
|
|
|
|
|
| |
(upcoming) non-raw logging namespace.
PiperOrigin-RevId: 462213222
Change-Id: I3b9371097b368d55cc86b6106d6dec24ce122762
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Some ABSL_RAW_LOG statements print off_t values by casting them to
uintmax_t. However, POSIX says off_t is signed [1], so intmax_t is more
appropriate. Replace casts and format specifiers as needed.
[1] https://pubs.opengroup.org/onlinepubs/009696899/basedefs/sys/types.h.html#:~:text=off_t%20shall,%20types%2e
PiperOrigin-RevId: 461684406
Change-Id: I09ec1a3ba49cd688670618797943a84bc48dba3e
|
|
|
|
|
|
|
| |
Add a hook to permit checking whether an address is in bounds for the stack.
PiperOrigin-RevId: 460997074
Change-Id: Ib3b4d0cf656e614aa083457abb079c40ef8db0ff
|
|
|
|
|
| |
PiperOrigin-RevId: 460752575
Change-Id: I9629504b5c63dbfe367cd55e287a782cd8fa546c
|
|\
| |
| |
| |
| | |
PiperOrigin-RevId: 460713135
Change-Id: If7ea94f409edc1e4024d7eaa4ae025b0b258fc02
|