instead of just trying to be MSVC
This also fixes the new warnings that are caught.
These include:
* Unreachable code after GTEST_SKIP (this is kind of ugly)
* Some -Wundef warnings
* A -Wshadow warning in vlog_config.cc
PiperOrigin-RevId: 838046186
Change-Id: Ief48d6db2b8755d2173997d052560880593d5819
instead of just trying to be MSVC
This also fixes the new warnings that are caught.
These include:
* Unreachable code after GTEST_SKIP (this is kind of ugly)
* Some -Wundef warnings
* A -Wshadow warning in vlog_config.cc
PiperOrigin-RevId: 838017208
Change-Id: I39373c0ccc57c8660c22815c51ac5b4180aec53c
This avoids a stack overflow when a large buffer is expected for stack traces.
The small/large threshold we use here is a heuristic to avoid going beyond one page of memory.
PiperOrigin-RevId: 792277857
Change-Id: I2a20ee830175192d0bc61d43ba13d7da10fe7aca
Together with the frame sizes already being returned, this gives us the bounds on each stack frame.
Note that this may slightly affect MSVC in debug builds, as it does not respect ABSL_ATTRIBUTE_ALWAYS_INLINE without optimizations. To remedy this, either enable inlining (/Ob1 or higher), or write a wrapper that ensures any stack traces obtained are robust to frames being added (such as by manually filtering everything below the caller).
Do not depend on the new APIs publicly. They are subject to change or removal.
PiperOrigin-RevId: 740075920
Change-Id: I6cd0909e7be3af4c9f32d39633230f655946b6a8
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
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
