...Replaced test mechanism for distinct address spaces with a more
reliable mechanism"
This reverts commit 5dd53ab6cb (svn
revision 167)
With this commit rhel 6.2 fails heap-checker-death_unittest and
without it passes.
Ticket refers to 2 things and both are invalid:
* that ptrace PEEKDATA ignores data argument. I've checked kernel
source and found it to be wrong
* something about distinct address spaces
And in addition to all that original ticket admits that it doesn't fix
anything.
It looks like, compared to original code that "fix" is not succesfully
wait-ing on parent's ptrace request. I.e. by adding some additional
diagnostics I'm seeing this sys_waitpid returning ECHILD.
Which gcc-3.4 (as shipped in rhel 4) doesn't like.
Cast to void * was originally added to avoid issue on OSX which
doesn't have sighandler_t.
In that place we only need to know if it's null or not. So casting to
intptr_t looks like simplest possible way to achieve that.
This merges patch by Nico Weber.
New clang versions complain in C++11 mode that:
error: cannot initialize a variable of type 'void *' with an rvalue of type 'uintptr_t' (aka 'unsigned long')
This same change was done for the google-internal version of tcmalloc too.
Reviewed-at: https://codereview.appspot.com/12132043
git-svn-id: http://gperftools.googlecode.com/svn/trunk@238 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
Because on OSX it calls malloc which leads to deadlock.
Given that we don't really need that fork handler _that_ early, it's
fine to change it to normal static initializer
git-svn-id: http://gperftools.googlecode.com/svn/trunk@235 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
This is patch by Adhemerval Zanella.
PowerPC uses 64K page size instead of 4k for x86 and x86_64. It makes the
page_heap_test fails because the following test:
static bool HaveSystemRelease =
TCMalloc_SystemRelease(TCMalloc_SystemAlloc(kPageSize, NULL, 0), kPageSize);
will always fail if kPageSize is less than getpagesize() (the default
configuration).
The following patch fixes it by trying to allocate/deallocate an entire
page instead.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@228 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
This is patch by Adhemerval Zanella.
* src/stacktrace_powerpc-inl.h: It is just a cleanup for the stacktrace
functions for PowerPC. The idea is to simplify the code.
* src/tests/heap-checker_unittest.cc: Handles the PPC64 function descriptor
correctly in malloc tracers. Different from other architecture, for PPC64
the address returned in function pointers are the ODP entry, not the
symbol address in .text segment. This leads the comparison bogus, since
it will compare a ODP entry with a .text address.
* src/heap-checker.cc: Add support for PPC in ptrace.
* src/base/elfcore.h: Likewise.
* src/base/linuxthreads.cc: Fix the thread creation using the clone wrapper.
* src/base/linux_syscall_support.h: Various fixes for PPC32 and PPC64:
fixes the kernel_stat[64] struct layout, and sys_clone and sys_socket
implementation.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@227 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
I.e. we have to check their presence in configure and in case of their
presence we have to avoid re-defining then in window's port.h
git-svn-id: http://gperftools.googlecode.com/svn/trunk@223 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
During issue-368 review it was correctly pointed out then in place
where I compare metadata allocation size to threshold I should pass
that size down to TCMalloc_SystemAlloc instead of threshold.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@217 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
While doing and testing issue-511 I've found one subtle bug which is
incorrect handling of short offsets. They are defined to be signed but
previous code used unsigned char for them which caused negative
offsets to look like larger positive offsets. Fix is trivial.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@215 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
Apparently Windows Server 2012 (and presumably windows 8) now has this
form of iat jump. Which is quite useless (rex.w is according to my
understanding is not needed at all) but because of rex.w our code to
recognize jumps like that didn't work.
Fix is just skip this prefix.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@214 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
I've found that Visual Studio 2012 release 32-bit C runtime library
patching fails because array new has rel8 jmp which previous code
could not handle.
Implementation is largely copied from conditional jumps handling code.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@213 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
It uses same approach as PageHeapAllocator. Namely allocates big chunk
which is then used to satisfy smaller allocations.
In issue-443 gradual heap grows causes old code that allocates
metadata in smaller pieces and thus more frequently to fragment the
heap. It's also causing most of 368 heap fragmentation too.
New code allocates 8 megs of address space at once for metadata
allocations. Most OSes will allocate actual memory only when
corresponding pages are touched. Thus this change should not cause
increased memory usage.
I've also made sure metadata is always properly aligned in case we
ever allocate something that breaks natural alignment. E.g. strings.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@211 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
Because unmapped spans are not coalesced with normal spans it's
possible that we indeed have a large enough free span, but we fail to
see that because we always consider unmapped and normal spans
separately. That behavior is more likely for larger spans.
In order to protect programs that grow heap frequently and by small
amounts from much more frequent minor page faults, there's limit of
running that force pages unmap path once per 128 megs of heap growth.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@210 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
Looks like my version of GCC is aware that free(malloc(X)) is a
no-op. So it optimizes that away completely ignoring simple fact that
we're observing malloc hooks invocations. By adding check that malloc
succeeded we force gcc to actually preserve that malloc call.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@208 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
Because automake will not automatically add AM_LDFLAGS if there's
per-target LDFLAGS. See their good info manual.
This fixes .dll compilation of tcmalloc
git-svn-id: http://gperftools.googlecode.com/svn/trunk@205 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
I.e. so that I can build tcmalloc.dll using comfortable environment of
my GNU/Linux box and without having to touch actual windows box or VM.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@202 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
So that it's easier to contribute and review contributions.
People wishing to build gperftools from svn checkout should run
autogen.sh first which will create those files and then ./configure &&
make as usual
INSTALL file has updated instructions too.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@200 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
Missing use of volatile was causing vs2010 to perform unwanted
optimization resulting in the crash. See issue for more details.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@198 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
gperftools was failing to build for arm targets for the following reasons:
1. Some ARMv7 instructions used when the target is ARMv6 so those fail to assemble
2. The cache line length is undefined for ARM architectures
git-svn-id: http://gperftools.googlecode.com/svn/trunk@197 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
tcmalloc contained a bug where some internal locks were left in a undefined state
between fork, leaving the child process in a deadlock state. This patch fixes the
issue by introducing stricter locking between the parent nd child while forking.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@196 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
This patch fixes issues where spinlocks under contention were failing to
wakeup waiters, sometimes resulting in blow ups from 13ns to as high as 256ms.
Under heavy contention, applications were observed sleeping for minutes at a
time giving the appearance of a hang.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@195 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
