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.
"mmap" hooks code for linux only hooks sbrk when __sbrk is
defined. But musl doesn't offer this function (reasonably so), so
sbrk hooking doesn't work there. Not big loss, but lets make sure
tests don't fail.
Lets reference this to issue #1198
Clang mostly ignores those anyways, so our tests needed better way to
disable optimizations (clang is quite aggressive replacing new/delete
pair with stack allocation).
The test relies on stuff "mmaper" function not being inlined, but
compilers are getting smarter and latest clang actually does inline it
now. Adding volatile to pointer declaration fixes it.
After change to release page heap lock around returning memory back to
kernel, page heap test got dependency on page heap lock. Which was not
available on windows since relevant symbols are not exported.
Proposed fix is to simply duplicate all needed .cc files in
page_heap_test project instead of linking to dll. This is not perfect
but gets job done, until we figure out better solution (GNU/Linux will
eventually get hidden visibility and will need it).
This fixes github issue 1189.
Whenever tcmalloc memfs allocator runs out of huge memory, it falls back to the
default system allocator, which will start allocating from normal anonymous
memory pool (small pages). For use cases that exclusively want hugepage backed
memory, such as using tcmalloc in combination with Intel SPDK, this is
problematic.
This change adds an environment variable "TCMALLOC_MEMFS_DISABLE_FALLBACK"
which when set to true will ensure that tcmalloc doesn't fallback to using the
system allocator when the system runs out of hugepages. This is false by
default, such that all other tcmalloc consumers will not see any changes.
For those curious, you can see part of our upstream SPDK work here:
https://review.gerrithub.io/c/spdk/spdk/+/475943
This patch adds visibility into the overhead due to fragmentation for each size
class in the tcmalloc central free list, which is helpful when debugging
fragmentation issues.
This fixes the following warning:
src/thread_cache.cc:281:10: warning: static member accessed through instance [readability-static-accessed-through-instance]
return sampler_.GetSamplePeriod();
^~~~~~~~~~~~~~~~~~~~~~~~
tcmalloc::Sampler::
