This reverts commit c9c5a40be1.
dwarf_get() returns 0 on success. We should continue unwinding
in that case.
TBD: investigate test-ptrace failure on some platforms.
If dwarf_get returns 0 (indicating the end of call chain), we should
not override the return value to 1. This may result in the caller
continuing to unwind and getting spurious errors.
In the commit d04dc94cc2, the check for
dwarf.ip == 0 was removed from non-dwarf walker in x86_64 version of
unw_step(). Apparently this broke the detection of the end of frame
chain when NULL %rbp is specified, because the case just marked
dwarf.ip as 0. Explicitly set ret to 0 to indicate the end of
iteration.
There is a window of time between the munmap and the tls_cache being
marked as destroyed, where there could be a bad access to memory that
has been unmapped/freed. Reorder the code a bit to close the window.
Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com>
The crashes were tracked down to f->rpb_cfa_offset being incorrect.
The problem is that {rsp,rbp}_cfa_offset only have 15 bits, but for
SIGRETURN frame they are filled with:
// src/x86_64/Gstash_frame.c
f->cfa_reg_offset = d->cfa - c->sigcontext_addr;
f->rbp_cfa_offset = DWARF_GET_LOC(d->loc[RBP]) - d->cfa;
f->rsp_cfa_offset = DWARF_GET_LOC(d->loc[RSP]) - d->cfa;
The problem is that the delta here can be arbitrarily large when
sigaltstack is used, and can easily overflow the 15 and 30-bit fields.
When signal handler starts running, the stack layout is:
... higher addresses ...
ucontext
CFA->
__restore_rt (== pretcode in rt_sigframe from
linux-2.6/arch/x86/include/asm/sigframe.h)
SP ->
... sighandler runs on this stack.
... lower addresses ...
This makes it very convenient to find ucontext from the CFA.
Attached patch re-tested on Linux/x86_64, no new failures.
Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com>
Reviwed-by: Lassi Tuura <lat@cern.ch>
Glibc calls thread-specific dtors in the order in which the keys were added,
so the first dtor is the trace_cache_free() one. Then thread-specific
data for some other key is free()d, which calls into unw_backtrace(),
which uses dangling cache and munmapped cache->frames.
[ Minor rename + compiler warning fix: asharma@fb.com ]
Signed-off-by: Paul Pluzhnikov <ppluzhnikov@google.com>
On FreeBSD, as well as on the Solaris < 10, weak pthread_once stub is
always exported from libc. But it does nothing, which means that if
threaded library is not loaded, then pthread_once() call do not actually
call the initializer finction. The construct
if (likely (pthread_once != 0))
{
pthread_once(&trace_cache_once, &trace_cache_init_once);
then fails to initialize the trace cache on x86_64.
Work around by checking that the initializer was indeed called.
Note that this can break if libthr is loaded dynamically, but my belief
is that there is no platforms which allow dynamic loading of the threading
library.
Insert static branch prediction predicates in useful places and avoid
unnecessary code in the hottest paths. Bypass unnecessary indirect
calls, in particular to access_mem(), when known to be safe.
Since the fast unwinding code path doesn't need the full context,
a faster target dependent getcontext is implemented.
Signed-off-by: Lassi Tuura <lat@cern.ch>
Dropping the extra frame for unw_backtrace itself using unw_step is
approximately 15% slower than skipping the frame in tdep_trace. So
drop the frame in the latter, and make the function a private
implementation detail for libunwind, not an exported interface.
Also moves unw_getcontext call back into unw_backtrace to avoid an
extra call frame in case slow_backtrace does not get inlined into
unw_backtrace.
Adds new function to perform a pure stack walk without unwinding,
functionally similar to backtrace() but accelerated by an address
attribute cache the caller maintains across calls.
the instruction after the call for a normal frame. libunwind uses
IP-1 to lookup unwind information. However, this is not necessary for
interrupted frames such as signal frames (or interrupt frames) in
the kernel context.
This patch handles both cases correctly.
Based on work by Mark Wielaard <mwielaard@redhat.com>
