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.
This patch adds aarch64 (arm64) ILP32 support by using
the proper syscalls for sys_fcntl(), sys_fstat(), sys_lseek()
and sys_mmap().
Signed-off-by: Christoph Müllner <christophm30@gmail.com>
The manpage of sbrk says that its argument is of type intptr_t.
This patch fixes a compiler warning on gcc 7.3.0.
Signed-off-by: Christoph Müllner <christophm30@gmail.com>
Recent commit to fix int overflow for implausibly huge allocation
added call to std::min. Notably, first arg was old size divided by
unsigned long 4. And on GNU/Linux i386 size_t is not long. So such
division was promoting first arg to unsigned long while second arg was
still size_t, so just unsigned. And that caused compilation to fail.
Fix is droping 'ul'.
Background context
------------------
crrev.com/1466173002 switched the GN tcmalloc target from source_set
-> static_library. There are good reasons for keeping tcmalloc a
source_set (see "Note on static libraries" in [1]). However, in the
current state source_set was exposing extra static initializers in the
GN build which, are not present in the gyp build due to the linker gc
sections.
Resolution of this CL
---------------------
The fact that vdso_support.cc is GC-ed by the linker is the symptom
that such code is unreachable. A search in the codebase shows that the
only client is stacktrace_x86-inl.h, which depends on VDSO only when
defined(__linux__) && defined(__i386__) This CL is therefore matching
this condition in vdso_support.h and conditioning the #define
HAVE_VDSO_SUPPORT with the same conditions.
[1] https://chromium.googlesource.com/chromium/src/+/master/tools/gn/docs/cookbook.md
References:
https://bugs.chromium.org/p/chromium/issues/detail?id=559766https://bugs.chromium.org/p/chromium/issues/detail?id=564618
This fixes test miscompilations on some clang 6.0
installations. Particularly issue #946.
Defines tested by tcmalloc.h where totally wrong defines. configure
actually puts defines of HAVE_DECL_FOOBAR kind in config.h. Which is
what we're using now.
This may fix issue #969.
When testing OOM handling we set up sys allocator that fails memory
allocation. But debugallocator itself allocates some internal metadata
memory via malloc and crashes if those allocations fail. So
occasionally this test failed when debugallocator's internal malloc
ended up causing sys allocator.
So instead of failing tests from time to time, we drop it for debug
allocator. It's OOM handling is already crashy anyways.
One of recent commits started passing kMaxPages to printf but not used
it. Thankfully compilers gave us warning. Apparently intention was to
print real value of kMaxPages, so this is what we're doing now.
Previously, the central free list with index '0' was always unused,
since freelist index 'i' tracked spans of length 'i' and there are no
spans of length 0. This meant that there was no freelist for spans of
length 'kMaxPages'. In the default configuration, this corresponds to
1MB, which is a relatively common allocation size in a lot of
applications.
This changes the free list indexing so that index 'i' tracks spans of
length 'i + 1', meaning that free list index 0 is now used and
freelist[kMaxPages - 1] tracks allocations of kMaxPages size (1MB by
default).
This also fixes the stats output to indicate '>128' for the large spans
stats rather than the incorrect '>255' which must have referred to a
historical value of kMaxPages.
No new tests are added since this code is covered by existing tests.
As reported in issue #954, osx clang compiler is able to optimize our
previous detection away while not really having runtime support for
sized delete. So this time we use AC_LINK_IFELSE and more robust code
to prevent compiler from optimizing away sized delete call. This
should reliably catch "bad" compilers.
Special thanks to Alexey Serbin for reporting the issue, suggesting a
fix and verifying it.
Fixes issue #954.
This is implemented via std::set with custom STL allocator that
delegates to PageHeapAllocator. Free large spans are not linked
together via linked list, but inserted into std::set. Spans also store
iterators to std::set positions pointing to them. So that removing
span from set is fast too.
Patch implemented by Aliaksey Kandratsenka and Todd Lipcon based on
earlier research and experimentation by James Golick.
Addresses issue #535
[alkondratenko@gmail.com: added Todd's fix for building on OSX]
[alkondratenko@gmail.com: removed unnecessary Span constructor]
[alkondratenko@gmail.com: added const for SpanSet comparator]
[alkondratenko@gmail.com: added operator != for STLPageHeapAllocator]
malloc_fast_path now receives oom function instead of full allocation
function and windows/patch_function.cc wasn't updated until now. It
caused assertion failures as reported in issue #944.
