tcmalloc contains some thread-safety annotations; however those
annotations have not been exercised for some time, as they used
macros/attributes only supported by a legacy branch of gcc.
Pull request #1251 converted those macros to support modern
versions of clang; this CR fixes the annotations that were
enabled. For the most part, this just requires re-enabling
annotations on member functions that take/release locks. For the
tcmalloc fork (pre-fork and post-fork) handlers, we mark the
functions as exempt from this analysis, as it takes a dynamic
number of locks.
tcmalloc contains its own copy of thread_annotations.h, wrapper
macros for static thread-safety analysis expressions. These thread-
safety expressions allow asserting (at compile time) that certain
locks are held or excluded or certain data is protected by specific
locks; they are checked at compile-time by recent versions of clang
or a gcc branch (https://gcc.gnu.org/wiki/ThreadSafetyAnnotation).
Convert the #if-guard and macro names from the no-longer-supported
gcc branch's defines & macros to the versions supported by recent
versions of clang.
Older glibc seemingly doesn't have right unwind info for signal frame,
so fails recently upgraded stacktrace_unittest. But since this version
is not supported anymore, lets just test newer glibc.
It is actually needed for libgcc backtracer from time to time. And
we've seen libunwind to need it too. Plus we've not heard of any
problems with it. So lets just always enable it.
This should fix github issue #1248.
Libunwind is mostly safe on x86-64 and most of OS (e.g. libc) is
compiled without frame pointers anyways. Even when libc is built with
frame pointers, various libc asm routines (e.g. memcpy) are not. And
even for code built with frame pointers we actually sometimes get
SIGPROF inside function prologues, before frame pointer is
established. Which then causes imperfect backtraces.
Libunwind should handle this all (when it doesn't crash or deadlock).
This supports frame pointer backtracing on x86-64, aarch64 and
riscv-s (should work for both 32 and 64 bits).
Also added is detection of borked libunwind on aarch64-s. In this case
frame pointer unwinder is preferred.
Previously it only was respected on x86_64, but this days lots of modern
ABIs are without frame pointers by default (e.g. arm64 and riscv, and
even older mips).
sigevent(7) is documented to have sigev_notify_thread_id as its member.
In glibc system, it's a macro expanded to the legacy _sigev_un._tid,
_sigev_un._tid is obviously an internal implementation detail as
signaled by its underscore prefix. And this macro was hidden inside
linux/signal.h in older version of glibc.
On Linux that use musl libc, sigev_notify_thread_id is also a macro, but
it's expanded to __sev_fields.sigev_notify_thread_id
[alkondratenko@gmail.com: amputated broken linux/signal.h dependency]
[alkondratenko@gmail.com: see https://github.com/gperftools/gperftools/pull/1250]
Signed-off-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
gperftools' internal atomicops library included atomic
Release Load and Acquire Store operations; those operations
were unused and expressed ordering constraints that aren't
expressible in the C++ standard memory model.
Remove them, to make a transition to C++11 atomics easier
and to avoid confusing use of them.
Mark arm64 register x8 as clobbered by syscall body inline assembly as
it is being used to store the syscall number. Otherwise the compiler
may try to use it for some other purpose.
This fix is derived from a resolution to clang Bugzilla report
https://bugs.llvm.org/show_bug.cgi?id=48798. See this report for a
minimal reproducer derived from the code fixed here as well as the
resolution.
This should fix SEGFAULTs as reported in
https://github.com/envoyproxy/envoy/issues/14756.
Fixes: #1241
Signed-off-by: Jarno Rajahalme <jarno@covalent.io>
This reverts commit be3da70298.
There are reports of crashes and false-positive OOMs from this
patch. Crashes under aggressive decommit mode are understood, but I
have yet to get confirmations whether false-positive OOMs were seen
under aggressive decommit or not. Thus lets revert for now.
Updates issue #1227 and issue #1204.
