This avoids a deadlock when a library which is being dlopen'ed creates
as part of its static constructors a thread which quickly need to call
malloc. We are still in the dlopen call (so with some internal glibc
mutex taken) when the thread executes code and later needs to call
malloc which in term calls tls_get_addr_tail, which wait for the dlopen
mutex to be unlocked. If later the dlopen'ing thread also calls malloc
as part of its constructors, we are in a deadlock.
Fix is similar to
7852eeb75b
Stack of the dlopening thread:
#0 0x00007fd5406ca93c in __lll_lock_wait () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0
#1 0x00007fd5406c45a5 in pthread_mutex_lock () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0
... proprietary code in the stack
#9 0x00007fd5074f0367 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at src/ClientImpl.cpp:15
#10 0x00007fd5074f06d7 in _GLOBAL__sub_I_ClientImpl.cpp(void) () at src/ClientImpl.cpp:85
#11 0x00007fd50757aa46 in __do_global_ctors_aux ()
#12 0x00007fd5073e985f in _init () from ...
#13 0x00007fd53bf9dec8 in ?? () from ...
#14 0x00007fd54d637a5d in call_init.part () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2
#15 0x00007fd54d637bab in _dl_init () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2
#16 0x00007fd54d63c160 in dl_open_worker () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2
#17 0x00007fd54d637944 in _dl_catch_error () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2
#18 0x00007fd54d63b7d9 in _dl_open () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2
#19 0x00007fd54d61f2b9 in dlopen_doit () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libdl.so.2
#20 0x00007fd54d637944 in _dl_catch_error () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2
#21 0x00007fd54d61f889 in _dlerror_run () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libdl.so.2
#22 0x00007fd54d61f351 in dlopen@@GLIBC_2.2.5 () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libdl.so.2
Stack of the newly created thread calling tls_get_addr_tail:
#0 0x00007fd5406ca93c in __lll_lock_wait () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0
#1 0x00007fd5406c4622 in pthread_mutex_lock () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0
#2 0x00007fd54d63a2ed in tls_get_addr_tail () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/ld-linux-x86-64.so.2
#3 0x00007fd53fee877d in tcmalloc::ThreadCache::CreateCacheIfNecessary () at src/thread_cache.cc:344
#4 0x00007fd53fecb4ab in tcmalloc::ThreadCache::GetCache () at src/thread_cache.h:437
#5 0x00007fd53fefeccb in (anonymous namespace)::do_malloc (size=56) at src/tcmalloc.cc:1354
#6 tcmalloc::do_allocate_full<tcmalloc::cpp_throw_oom> (size=56) at src/tcmalloc.cc:1762
#7 tcmalloc::allocate_full_cpp_throw_oom (size=56) at src/tcmalloc.cc:1776
#8 0x00007fd53ff01b80 in tcmalloc::dispatch_allocate_full<tcmalloc::cpp_throw_oom> (size=56) at src/tcmalloc.cc:1785
#9 malloc_fast_path<tcmalloc::cpp_throw_oom> (size=56) at src/tcmalloc.cc:1845
#10 tc_new (size=56) at src/tcmalloc.cc:1980
... proprietary code in the stack
#26 0x00007fd5406c1ef4 in start_thread () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libpthread.so.0
#27 0x00007fd5403ba01d in clone () from /data3/mwrep/rgeissler/core.tls/opt/1A/toolchain/x86_64-2.6.32-v2/lib64/libc.so.6
In some architectures (e.g. powerpc, powerpc64 and powerpc64le), the
macro that specifies the position of the program counter is defined in
header asm/ptrace.h.
When glibc bug 21457 got fixed in version 2.27, header sys/ucontext.h
stopped including signal.h, which indirectly removed asm/ptrace.h too.
Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
mmap64 can already been defined and as a result the following error is
raised:
In file included from src/malloc_hook.cc:686:0:
src/malloc_hook_mmap_linux.h: In function ‘void* mmap(void*, size_t, int, int, int, off_t)’:
src/malloc_hook_mmap_linux.h:173:18: error: redefinition of ‘void* mmap(void*, size_t, int, int, int, off_t)’
extern "C" void* mmap(void *start, size_t length, int prot, int flags,
^~~~
In file included from src/malloc_hook.cc:41:0:
src/malloc_hook_mmap_linux.h:159:18: note: ‘void* mmap(void*, size_t, int, int, int, off_t)’ previously defined here
extern "C" void* mmap64(void *start, size_t length, int prot, int flags,
^
Makefile:4874: recipe for target 'src/libtcmalloc_minimal_internal_la-malloc_hook.lo' failed
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
__sbrk is not defined in musl so add a check for it in configure.ac and
replace the check on ifndef __UCLIBC__ by a check on ifdef HAVE__SBRK
in src/malloc_hook_mmap_linux.h
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
__off64_t is a kernel internal symbol, which happens to be user-visible
with glibc, but not necessarily with other C libraries such as musl.
Switching from __off64_t to off64_t allows the code to build properly
with musl.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Original CL:
- https://codereview.chromium.org/1410353005
Add generic.total_physical_bytes property to MallocExtension
The actual physical memory usage of tcmalloc cannot be obtained by
GetNumericProperty. This accounts for the current_allocated_bytes,
fragmentation and malloc metadata, and excludes the unmapped memory
regions. This helps the user to understand how much memory is actually
being used for the allocations that were made.
Reviewed-on: https://chromium-review.googlesource.com/1130803
Everyone should be using golang pprof from github.com/google/pprof, but
distros still ship our perl version and not everyone is aware of
better pprof yet.
This is another step in completely dropping perl pprof. We still
default to installing it, but hopefully we'll be able to convince
distros to disable this soon.
We still install pprof under pprof-symbolize name because
stack traces symbolization depends on it, and because golang pprof
won't support this feature.
This is related to issue #1038.
This is one of the things that chrome's fork fixes, but with c++11 we
can do it even nicer. Proposed fix is to use c++11 local static
variable to ensure that pprof path is initialized once on as-needed
basis.
1.Remove superfluous per file settings for include directory and runtime library.
2.Remove unnecessary project tcmalloc_minimal_unittest-static. We can simply build libtcmalloc_minimal as a static library and then link against the single .lib file.
3.Add separate configurations of patching and overriding facility for release mode.
After 71fa9f87 (use 2-level page map for 48-bit addresses), there is a
potential for allocs of additional leaves in the middle of the test.
With ASLR enabled on amd64 (without TCMALLOC_SMALL_BUT_SLOW), this
results in the test failing sometimes (< 1% of the time). Instead, make
sure all those leaves are allocated before deciding on the baseline heap
usage in the test.
We aliased functions with different signatures and gcc now correctly
gives warning for that. Originally gcc 5 same code merging feature
caused us to alias more than necessary, but I am not able to reproduce
this problem anymore. So we're now aliasing only compatible functions.
GCC was giving warning on snprintf and it hinted at base_profile_name
and full_profile_name not being long enough.
Fix is to ensure base_profile_name is long enough for PATH_MAX and
that full_profile_name is enough longer to fit extra chars.
Like _free_base, _free_dbg is called by CRT internal functions or
operator delete in Debug mode.
This closes#719 and closes#894.
[alkondratenko@gmail.com: trivial formatting fixes]
[alkondratenko@gmail.com: build free_dbg even in release builds]
A few files in the windows port that haven't been touched in a long time,
use non-utf8 codes for special symbols, breaking a presubmit checker in
Chromium.
Modifies the Windows addr2line wrapper to expect addresses relative to
DllBase to better simulate how addr2line works with modules in Linux.
Windows DLLs have a concept of "default load address" which hints to the OS
where to load the binary image after relocation. The dbghelp.dll
symbolization library will load the module at this location in the virtual
address space meaning the caller of these functions would need to be aware
of the base address. This makes things unnecessarily complex in the face of
ASLR and also diverges from the behavior of addr2line when used with linux-
style DSOs. This CL simply adds the module base address to the incoming
addresses, thereby making the input relative addresses for the module which
both is easier to use and lines up better with linux's addr2line behavior.
These changes were made originally as part of CL
https://codereview.chromium.org/2730473002.
BUG=724399,b:70905156
Change-Id: I0abe9e0c380e7e60ae29a11021bb805b31718d08
Fixes a few small format string bugs and makes the windows library
configuration #defines more friendly for chromium builds.
Based on original CL: https://codereview.chromium.org/2730473002
BUG=724399,b:70905156
Change-Id: If54c6cfc5c508744d2ee18f251677b2456acda72
Sampler's documentation states the following:
C++03 requires that types stored in TLS be POD. As a result, you must
initialize these members to {0, 0, false} before using this class!
However, the test code wasn't doing that. MemorySanitizer and
UndefinedBehaviorSanitizer both failed because of it.
At first I try to add some functions as what Chrome does at their
https://chromium.googlesource.com/chromium/src/+/master/base/allocator/allocator_shim_override_ucrt_symbols_win.h,
but it still fails. So I decide to remove all heap-related objects
from libucrt.lib to see what happens. At the end I find that a lot of
functions in the CRT directly invoke _malloc_base instead of
malloc (and the others alike), hence we need to override them as well.
This should close issue #716.
[alkondratenko@gmail.com: added reference to ticket]
Signed-off-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
It looks like previous fix introduced another warning on gcc for
i386. Somehow it barked on kAddressBits shift even that shift was dead
code.
Anyways, we now avoid possibility of undefined shift even
stronger. And it actually removes compile warning on all compilers I
tested.
Only add -static to malloc_bench_LDFLAGS and binary_trees_LDFLAGS if
ENABLE_STATC is set otherwise build with some compilers will fail if
user has decided to build only the shared version of gperftools
libraries
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Powerpc requires VDSO support in order to produce a stack trace.
Without this, it isn't possible to complete a build.
Tested on powerpc, powerpc64 and powerpc64le.
