mzhaom / gperftools Goto Github PK

What steps will reproduce the problem?
1. g++ myprogram.c -ltcmalloc -lpthread  when only libtcmalloc.a is present
2. gcc myprogram.c -ltcmalloc -lpthread 
3.

What is the expected output? What do you see instead?

Expect an executable a.out, but get the following instead:

.//libtcmalloc_minimal.a(libtcmalloc_minimal_la-tcmalloc.o)(.text+0x2bba):
In function `TCMalloc_PageHeap::GrowHeap(unsigned long)':
src/tcmalloc.cc:1253: undefined reference to `GetStackTrace(void**, int, int)'
.//libtcmalloc_minimal.a(libtcmalloc_minimal_la-tcmalloc.o)(.text+0x38b6):
In function `do_malloc(unsigned long)':
src/tcmalloc.cc:2601: undefined reference to `GetStackTrace(void**, int, int)'
.//libtcmalloc_minimal.a(libtcmalloc_minimal_la-malloc_hook.o)(.text+0x19c):
In function `MallocHook::GetCallerStackTrace(void**, int, int)':
src/malloc_hook.cc:346: undefined reference to `GetStackTrace(void**, int,
int)'
.//libtcmalloc_minimal.a(libtcmalloc_minimal_la-malloc_hook.o)(.text+0x2b6):src/
malloc_hook.cc:221:
undefined reference to `GetStackTrace(void**, int, int)'
collect2: ld returned 1 exit status

What version of the product are you using? On what operating system?

0.94.1 on Linux on x86_64 (Opteron).

Please provide any additional information below.

There are many more undefined symbol errors when gcc is used to link
instead of g++.

What steps will reproduce the problem?
1. Download the .tar.gz to an x86_64 machine
2. ./configure
3. make

What is the expected output? What do you see instead?

I see build errors like this:
 g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -I/home/mrabkin/unwind/include
-pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual
-Wno-sign-compare -DNO_FRAME_POINTER -g -O2 -MT
libtcmalloc_minimal_la-malloc_hook.lo -MD -MP -MF
.deps/libtcmalloc_minimal_la-malloc_hook.Tpo -c src/malloc_hook.cc  -fPIC
-DPIC -o .libs/libtcmalloc_minimal_la-malloc_hook.o
src/base/linux_syscall_support.h: In function 'ssize_t sys_pread64(int,
void*, size_t, loff_t)':
src/base/linux_syscall_support.h:2733: error: '__NR_pread64' was not
declared in this scope
src/base/linux_syscall_support.h: In function 'ssize_t sys_pwrite64(int,
const void*, size_t, loff_t)':
src/base/linux_syscall_support.h:2735: error: '__NR_pwrite64' was not
declared in this scope
make: *** [libtcmalloc_minimal_la-malloc_hook.lo] Error 1


What version of the product are you using? On what operating system?

$ uname -a
Linux <hostname> 2.6.12-1.1398_FC4smp #1 SMP Fri Jul 15 01:05:24 EDT 2005
x86_64 x86_64 x86_64 GNU/Linux

Please provide any additional information below.

I looked in the offending .h file, and it does seem that __NR_pread64 is
simply not defined for x86_64 systems.

What steps will reproduce the problem?
1. ./configure
2. make

What is the expected output? What do you see instead?

Compilation fails straight out of the box with the following error:

if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.
-I./src  -I./src   -g -O2 -MT thread_lister.lo -MD -MP -MF
".deps/thread_lister.Tpo" -c -o thread_lister.lo `test -f
'src/base/thread_lister.c' || echo './'`src/base/thread_lister.c; \
then mv -f ".deps/thread_lister.Tpo" ".deps/thread_lister.Plo"; else rm -f
".deps/thread_lister.Tpo"; exit 1; fi
 gcc -DHAVE_CONFIG_H -I. -I. -I./src -I./src -g -O2 -MT thread_lister.lo
-MD -MP -MF .deps/thread_lister.Tpo -c src/base/thread_lister.c 
-fno-common -DPIC -o .libs/thread_lister.o
src/base/thread_lister.c:35:23: error: sys/prctl.h: No such file or directory
src/base/thread_lister.c: In function 'ListAllProcessThreads':
src/base/thread_lister.c:53: error: 'PR_GET_DUMPABLE' undeclared (first use
in this function)
src/base/thread_lister.c:53: error: (Each undeclared identifier is reported
only once
src/base/thread_lister.c:53: error: for each function it appears in.)
src/base/thread_lister.c:55: error: 'PR_SET_DUMPABLE' undeclared (first use
in this function)
make: *** [thread_lister.lo] Error 1


What version of the product are you using? On what operating system?

google-perftools-0.92.tar.gz, on a PowerBook Pro (uname -a: Darwin
tampa.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT
2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386)

Please provide any additional information below.

What steps will reproduce the problem?
1. ./configure && make && make check 2>&1 > google-perftools_unittest.out

What is the expected output? What do you see instead?
2 out of the 19 tests fail

What version of the product are you using? On what operating system?
google-perftools0.91.tar.gz

Please provide any additional information below.
coleb@sled10/tmp/coleb/google-perftools-0.91$ cat /etc/SuSE-release
SUSE Linux Enterprise Desktop 10 (i586)
VERSION = 10

Using the default system compiler. 

Just needed the profiler for now, works great by the way, thank you. May
poke into the tcmalloc and the heap checker later in life. 

The current RPM includes a libprofiler.so symlink, but the files it points
to (libprofiler.so.0.0.0) is not included in the RPM.

What steps will reproduce the problem?
1. Run many times calloc and malloc (1024000 times)
Calloc() works more slower than malloc().
I think that memset() that used inside calloc() works too slow. 

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
google-perftools-0.91 compiled from sources with
gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)
Linux 2.6.20-1.2319.fc5 i686 i686 i386 GNU/Linux

Please provide any additional information below.

What steps will reproduce the problem?
1. Install from .deb
2. Try to link with a program via g++ -lprofiler

What is the expected output? What do you see instead?
Expected link, but got "can not find libprofiler"

What version of the product are you using? On what operating system?
Current Ubuntu release.

Please provide any additional information below.
Fixed by adding "sudo ln -s /var/lib/libprofiler.so.0.0.0
/var/lib/libprofiler.so" but this should be handled via the .deb

What steps will reproduce the problem?
1. ./configure 
2. checking location of STL hash_map...
configure: error: couldn't find an STL hash_map

3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Linux server 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:32:02 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux

Please provide any additional information below.

I have been trying to install google-perftools on this erver for sometime 
but it keeps giving me above mentioned error . 
I have following rpms installed 

[root@server software]# rpm -qa |grep c++
compat-libstdc++-296-2.96-132.7.2
libstdc++-3.4.6-3
libstdc++-devel-3.4.6-3
compat-gcc-32-c++-3.2.3-47.3
compat-libstdc++-33-3.2.3-47.3
libstdc++-3.4.6-3
libstdc++-devel-3.4.6-3
[root@l065t06 software]# rpm -qa gcc
gcc-3.4.6-3
[root@server software]# rpm -qa |grep gcc
libgcc-3.4.6-3
compat-gcc-32-c++-3.2.3-47.3
libgcc-3.4.6-3
gcc-3.4.6-3
compat-gcc-32-3.2.3-47.3


It installed fine on Redhat enterprise 3 update 4 . with 2.4.21-27.ELsmp kernel

What steps will reproduce the problem?
1. Download and install openSUSE 10.3
2. Download and unzip/untar google-perftools-0.94.1.tar.gz
3. Run ./configure && make && make check

What is the expected output? What do you see instead?
All tests pass.

What version of the product are you using? On what operating system?
openSUSE 10.3
$ rpm -q libunwind
libunwind-0.98.5-78
$ rpm -q glibc
glibc-2.6.1-18.3
$ rpm -q gcc
gcc-4.2-24

Please provide any additional information below.

Output of make check:
FAIL: heap-checker_unittest.sh
FAIL: heap-checker-death_unittest.sh
FAIL: profiler_unittest.sh
======================================
3 of 22 tests failed
Please report to [email protected]
====================================== 

heap_checker.cc has
#ifdef HAVE___ATTRIBUTE___
in front of the code to override the initial malloc hooks.
but the define that is made when attributes are available is one underscore
shorter: HAVE___ATTRIBUTE__

so the initial malloc_hook override never occurs on any platform.
this can lead to bad answers from the heap checker if it then misses early
calls to sbrk or mmap.

What steps will reproduce the problem?
1. set HEAP_PROFILE_MMAP_LOG to true
2. set HEAP_PROFILE_MMAP to true
3. run HEAPPROFILE=/user/kgx02018/temp/mem.hprof   a.out



What is the expected output? What do you see instead?
The binary never terminates. It is expected to terminate immediately. I
used a very small example program.

What version of the product are you using? On what operating system?
I am using 
Linux demuxetc 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686
i386 GNU/Linux
and using 0.91.1 (latest release).


Please provide any additional information below.

This is a first attempt to get libtcmalloc_minimal running on Mac OS X.

I haven't tested extensively, but passes the tests on ppc and x86.

The current source tarball, does not include the file
cpuprofile-fileformat.html in the doc directory. It is available online,
but cpuprofile.html in doc has a link to it.

(First, thank you very much for providing the latest release --- with the
one fix below, it compiles on RHEL4 x86_64 and even seems to be working
with C++ exceptions.)

What steps will reproduce the problem?
1. LDFLAGS=-L../libunwind/lib CPPFLAGS=-I../libunwind/include ./configure
2. make 

Error message:

src/stacktrace_libunwind-inl.h:68: error: `ret' was not declared in this scope

This patch lets it build:

--- t/google-perftools-0.90/src/stacktrace_libunwind-inl.h      2007-04-12
17:25:50.000000000 -0700
+++ google-perftools-0.90/src/stacktrace_libunwind-inl.h        2007-04-16
17:15:46.000000000 -0700
@@ -65,12 +65,12 @@
   }

   unw_getcontext(&uc);
-  ret = unw_init_local(&cursor, &uc);
+  int ret = unw_init_local(&cursor, &uc);
   assert(ret >= 0);
   skip_count++;         // Do not include the "GetStackTrace" frame

   while (n < max_depth) {
-    int ret = unw_get_reg(&cursor, UNW_REG_IP, (unw_word_t *) &ip);
+    ret = unw_get_reg(&cursor, UNW_REG_IP, (unw_word_t *) &ip);
     if (ret < 0)
       break;
     if (skip_count > 0) {


What version of the product are you using? On what operating system?
google-perftools-0.90, RHEL4 on x86_64, gcc-3.4.6, libunwind-snap-070410.


Please provide any additional information below.

Full command and error:

$ make
if /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.
-I./src  -I./src -I/home/rickcox/local/include -DNO_FRAME_POINTER -g -O2
-MT stacktrace.lo -MD -MP -MF ".deps/stacktrace.Tpo" -c -
o stacktrace.lo `test -f 'src/stacktrace.cc' || echo './'`src/stacktrace.cc; \
then mv -f ".deps/stacktrace.Tpo" ".deps/stacktrace.Plo"; else rm -f
".deps/stacktrace.Tpo"; exit 1; fi
mkdir .libs
 g++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src -I/home/rickcox/local/include
-DNO_FRAME_POINTER -g -O2 -MT stacktrace.lo -MD -MP -MF
.deps/stacktrace.Tpo -c src/stacktrace.cc  -fPIC -DPIC -o .libs/stacktrac
e.o
In file included from src/stacktrace.cc:71:
src/stacktrace_libunwind-inl.h: In function `int GetStackTrace(void**, int,
int)':
src/stacktrace_libunwind-inl.h:68: error: `ret' was not declared in this scope

What steps will reproduce the problem?
1. Suppose thread A and thread B both call SpinLock::Lock on the same lock.
2. Suppose A calls InterlockedCompareExchange (in the
perftools_pthread_once macro) and it returns 0.
3. Suppose B then calls InterlockedCompareExchange and it returns 1.
4. Suppose B then calls EnterCriticalSection.
5. But sometime later A calls (init)() which calls InitializeCriticalSection.
6. B entered the critical section before A initialized it.

What is the expected output? What do you see instead?
Expected the critical section to be initialized before being entered. In
fact, expected perftools_pthread_once to only return if init() had been
called (by the current or some other thread) to match pthreads behavior, so
this isn't specific to the SpinLock.

What version of the product are you using? On what operating system?
Pertools 0.93. Windows XP. Visual Studio 2005. Intel X86.

Please provide any additional information below.
Haven't seen this in practice, but seems like a potential problem. One
possible fix to perftools_pthread_once is to make 'once' have three
possible states. It starts out 0, and the first thread to CompareExchange
it to 1 calls init() then sets it to 2 and returns. If CompareExchange
returns 2 we know init() had been called so return from the macro.
Otherwise if CompareExchange returns 1 we know it's in the process of being
initialized by some other thread, so Sleep(0) (i.e. yield) and loop to
check again.

What steps will reproduce the problem?
1. ./configure
2. make
3. make install
4. mv <INSTALL_DIR>/lib/*.so <SOMEWHERE_ELSE>
5. ldd <SOMEWHERE_ELSE>/libtcmalloc.so          // not found
6. LD_LIBRARY_PATH=:<SOMEWHERE_ELSE>
7. ldd <SOMEWHERE_ELSE>/libtcmalloc.so          // should be found !

What is the expected output? What do you see instead?
I expected to see:
  libstacktrace.so.0 not found                  // after step 5
  libstacktrace.so.0 (0x0000002a959b1000)       // after step 7
I got:
  libstacktrace.so.0 not found                  // after step 5
  libstacktrace.so.0 not found                  // after step 7

What version of the product are you using? On what operating system?
0.95.1 
Linux_rh9, Linux_x86_64 and Linux_x86_64_rhel3

Please provide any additional information below.

I found out that the problem is caused by one line in libtool.
Using --rpath hardcodes the libpath into the shared lib.
--rpath-link allows searching the library after linking it.

0.95.1:
294: hardcode_libdir_flag_spec="\${wl}--rpath \${wl}\$libdir"

Fixed:
294: hardcode_libdir_flag_spec="\${wl}--rpath-link \${wl}\$libdir"

What steps will reproduce the problem?
1. ./configure
2. gmake

What is the expected output? What do you see instead?
the following error happens:
src/base/linux_syscall_support.h: In function `void* sys_mmap(void*,
size_t, int, int, int, __off64_t)':
src/base/linux_syscall_support.h:339: error: invalid conversion from `long
int' to `void*'
gmake: *** [libtcmalloc_minimal_la-malloc_hook.lo] Error 1


What version of the product are you using? On what operating system?
> ls -l ../google-perftools-0.8.tar.gz
-rw-r--r--  1 user group 759810 Mar 27 15:33 ../google-perftools-0.8.tar.gz

>  uname -a
Linux hostname 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:56:28 EST 2006 x86_64
x86_64 x86_64 GNU/Linux

Please provide any additional information below.

32bit rpm is available, could not find it for 64 bit. It will be useful to
have 64bit rpm in downloads section.

Fedora gets rid of the rpath for our packages, and when we do so, we expose
linking failures in the test cases.

This patch resolves the link failures.

What steps will reproduce the problem?
1. export LD_LIBRARY_PATH=/opt/xyz/jre/lib/i386:$LD_LIBRARY_PATH
2. export LD_PRELOAD=/opt/xyz/lib/libtcmalloc_minimal.so
3. bin/java

What is the expected output? What do you see instead?
Program shud not dump core, instead it fails:

Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC                = 0xb74b7fe7
SIGNAL            = 7
FUNCTION NAME     = (N/A)
OFFSET            = 0xFFFFFFFF
LIBRARY NAME      = (N/A)
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.
Aborted (core dumped)


What version of the product are you using? On what operating system?
RHAS 3, SLES 8

Please provide any additional information below.

What steps will reproduce the problem?

#include <ole2.h>
int main(void)
{
  OleInitialize(NULL);
  return 0;
}

What version of the product are you using? On what operating system?

Windows XP, tested with 0.94 and 0.96
same result for both MSVC and MinGW builds

Please provide any additional information below.

Access to a NULL pointer happens at line 2711 of tcmalloc.cc, in do_free():

cl = span->sizeclass;

span is NULL

What steps will reproduce the problem?
1. when compiling Reaim
2.
3.

What is the expected output? What do you see instead?
Without linking -ltcmollac
gcc: -lm: linker input file unused because linking not done
/bin/sh ../libtool --tag=CC --mode=link gcc  -W -Wall -lm -ffloat-store -g
-O -D_GNU_SOURCE -DSHARED_OFILE   -o reaim  driver.o ram.o rand.o
times_ms.o add.o creat_clo.o drv_funcs.o div.o disk_funcs.o pipe_test.o
mul.o num_fcns.o int_fcns.o disk1.o disk_src.o fun.o funcal.o -laio
../lib/libltp.a
gcc -W -Wall -ffloat-store -g -O -D_GNU_SOURCE -DSHARED_OFILE -o reaim
driver.o ram.o rand.o times_ms.o add.o creat_clo.o drv_funcs.o div.o
disk_funcs.o pipe_test.o mul.o num_fcns.o int_fcns.o disk1.o disk_src.o
fun.o funcal.o  -lm -laio ../lib/libltp.a
creat_clo.o: In function `creat_clo':
/autobench/sources/reaim/src/creat_clo.c:573: warning: the use of `mktemp'
is dangerous, better use `mkstemp'
make[2]: Leaving directory `/autobench/sources/osdl-aim-7/src'
make[2]: Entering directory `/autobench/sources/osdl-aim-7'
make[2]: Leaving directory `/autobench/sources/osdl-aim-7'
make[1]: Leaving directory `/autobench/sources/osdl-aim-7'



With -ltcmalloc
/bin/sh ../libtool --tag=CC --mode=link gcc  -W -Wall -lm -ffloat-store -g
-O -D_GNU_SOURCE -ltcmalloc -DSHARED_OFILE   -o reaim  driver.o ram.o
rand.o times_ms.o add.o creat_clo.o drv_funcs.o div.o disk_funcs.o
pipe_test.o mul.o num_fcns.o int_fcns.o disk1.o disk_src.o fun.o funcal.o
-laio ../lib/libltp.a
gcc -W -Wall -ffloat-store -g -O -D_GNU_SOURCE -DSHARED_OFILE -o reaim
driver.o ram.o rand.o times_ms.o add.o creat_clo.o drv_funcs.o div.o
disk_funcs.o pipe_test.o mul.o num_fcns.o int_fcns.o disk1.o disk_src.o
fun.o funcal.o  -lm -ltcmalloc -laio ../lib/libltp.a
creat_clo.o: In function `creat_clo':
/autobench/sources/osdl-aim-7-tcmalloc/src/creat_clo.c:573: warning: the
use of `mktemp' is dangerous, better use `mkstemp'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_key_create'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_once'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_getspecific'
/usr/local/lib/libtcmalloc.so: undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
make[2]: *** [reaim] Error 1
make[2]: Leaving directory `/autobench/sources/osdl-aim-7-tcmalloc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/autobench/sources/osdl-aim-7-tcmalloc'
make: *** [all] Error 2


What version of the product are you using? On what operating system?
google-perftools-0.91.tar.gz
libunwind-snap-070410.tar.gz

On RHEL5 GA and SLES10

Please provide any additional information below.

If export LD_PRELOAD="/usr/local/lib/libtcmalloc.so"

# env
env: symbol lookup error: /usr/local/lib/libtcmalloc.so: undefined symbol:
pthread_key_create

What steps will reproduce the problem?
1. Build libtcmalloc_minimal in Release mode.
2.
3.

What is the expected output? What do you see instead?
Linking...
MSVCRT.lib(MSVCR71.dll) : error LNK2005: _free already defined in tcmalloc.obj
MSVCRT.lib(MSVCR71.dll) : error LNK2005: _malloc already defined in
tcmalloc.obj
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: _free already defined in
tcmalloc.obj; second definition ignored
MSVCRT.lib(MSVCR71.dll) : warning LNK4006: _malloc already defined in
tcmalloc.obj; second definition ignored
   Creating library
D:\GoogleCode\perftools\google-perftools-0.92\Release/libtcmalloc_minimal.lib
and object
D:\GoogleCode\perftools\google-perftools-0.92\Release/libtcmalloc_minimal.exp
D:\GoogleCode\perftools\google-perftools-0.92\Release/libtcmalloc_minimal.dll
: fatal error LNK1169: one or more multiply defined symbols found

libtcmalloc_minimal - 3 error(s), 2 warning(s)


What version of the product are you using? On what operating system?
0.92 on Windows 2003

Please provide any additional information below.

What steps will reproduce the problem?
1. /configure --enable-frame-pointers --disable-shared
2. make

What is the expected output? What do you see instead?
Got the following linker error:
/bin/sh ./libtool --tag=CXX --mode=link g++ -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare   -g -O2   -o heap-profiler_unittest
-g -D_THREAD_SAFE  heap_profiler_unittest-heap-profiler_unittest.o 
libstacktrace.la libtcmalloc.la  
g++ -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -g -O2 -o
heap-profiler_unittest -g -D_THREAD_SAFE
heap_profiler_unittest-heap-profiler_unittest.o -Wl,-bind_at_load 
./.libs/libstacktrace.a ./.libs/libtcmalloc.a
/Users/coleb/OEThreading/OEThreadingNoMemPool/OEThreadingNoMemPoolTCMalloc/googl
e-perftools-0.95.1/.libs/libstacktrace.a
ld: duplicate symbol SpinLock::SlowLock()     in
./.libs/libtcmalloc.a(spinlock.o) and ./.libs/libstacktrace.a(spinlock.o)

collect2: ld returned 1 exit status
make: *** [heap-profiler_unittest] Error 1


What version of the product are you using? On what operating system?
google-perftools-0.95.1 on Mac OS X 10.5 (Leopard)

I've tested 0.93 on Leopard and it builds fine. 


Please provide any additional information below.
I successfully built 0.95.1 on Mac OS X 10.4 (Tiger)

What steps will reproduce the problem?
1. Compile with Visual Studio 2005, /O2
2. Disassemble do_free
3. Note that "size_t cl = pageheap->GetSizeClassIfCached(p);" accesses
page_heap.pagemap_cache_.array_ twice (in PackedCache::GetOrDefault the
existence of the local variable 'entry' does not enforce only one read of
array_, so it is not an atomic read)
3a. Another thread may have changed the cached value in array_ between the
first and second read, so GetOrDefault returns a bogus result, which causes
badness later on.

What is the expected output? What do you see instead?
Expected GetOrDefault to read array_ atomically.

What version of the product are you using? On what operating system?
PerfTools version 0.93. Windows XP. Intel X86. Visual Studio 2005.

Please provide any additional information below.
Changing the PackedCache::array_ to be volatile appears to fix this issue.

What steps will reproduce the problem?
1. build the library, redirecting all the build output to a file
2. actually look at the file

What is the expected output? What do you see instead?
No errors or warnings (at all!).
Lots of warnings.

What version of the product are you using? On what operating system?
google-perftools-0.92; RHEL WS release 4 (Nahant Update 5)

Please provide any additional information below.
I have a simple Perl script that scans log files from builds, looking
for compiler errors and warnings.  It extracts a distinguishing subset
of each message, and accumulates the number of each type of message.
When run on a build of just the perftools library, it yields:

================================================================
259 code warnings   (259 known,   0 unknown)
----------------------------------------------------------------
    8   after first use results in unspecified behavior
  120   comparison between signed and unsigned
    4   matching constraint does not allow a register
    2   left shift count >= width of type
    2   long long unsigned int format, different type arg
  123   unused parameter
================================================================

I can't see any reason why any of these should have made it out into
public view, and some of these look downright dangerous.

Think carefully about how you patch these problems.  Don't just put in
casts to make the compiler shut up, if that doesn't accurately fix the
underlying issue.

Once you've dealt with all the messages found on one platform/compiler,
switch to other platforms and other compilers, and iterate.  Different
compilers will observe and report on different problems.  Especially
try compilers of completely different provenance, such as g++ and
Sun Studio.

What steps will reproduce the problem?
Just run port on FreeBSD

What version of the product are you using? On what operating system?
0.96

Patch is attached.

Thanks.

What steps will reproduce the problem?
1. Perform SVN Checkout with TortoiseSVN on Windows. Repository URL:
http://google-ctemplate.googlecode.com/svn/trunk

What is the expected output? What do you see instead?
I expected to receive the latest bleeding edge perftools source code, but
all I got were documentation files.

What version of the product are you using? On what operating system?
I am using TortoiseSVN 1.4.1 on Windows XP Professional

Please provide any additional information below.
The file attached is the list of files, including the SVN files, that I got
from the checkout.

Easy to fix though, just a few new includes, nothing that breaks backwards
compatibility with older gcc.

Patch attached.

Hi,

I am considering using tcmalloc in a complex, highly-multithreaded system
daemon on the Linux platform (which, coincidentally, was sponsored by
Google :).

However, I am experiencing abnormally high memory usage (as reported by
RSS) on some allocation patterns.

On one particular real-world case, in which almost all allocations are
performed by a set of 40 threads, although no more than 340 MB are
allocated at the same time, the daemon is using more than 560 MB of RSS.
This happens only after 5-10 minutes of (intense) usage.

A heap profile reports that in 301 MB of allocated memory, 85.2 MB (28.3%)
are 1000-byte blocks and 76.4 MB (25.4%) are 648-byte blocks. I believe,
although I'm not sure, another 76.5 MB (25.4%) are blocks sized somewhere
between 512 bytes and 128 KB (and should be a multiple of 512 bytes).

I tried making a small test case, but I stumbled upon the problem that
simply allocating a lot of small blocks and subsequently deallocating them
never returns the memory back to the OS.

The daemon can never be restarted since it implements a filesystem (through
FUSE), and of course preferentially it should release unused memory back to
the OS.

Do you think I will be able to use tcmalloc for this application?

I tried using several memory allocators, and only one - libumem - performs
satisfactorily in terms of memory usage on a few test cases, but it still
has *very* high long-term memory fragmentation (there are no memory leaks).

Thanks.

What steps will reproduce the problem?
1. tcmalloc compile(./configure; make)
2. LD_PRELOAD=./libtcmalloc.so ./a.out
3. pstack [pid]

display below stack

#0 0xa000000000010641 in __kernel_syscall_via_break () 
#1 0x2000000000127480 in __lll_lock_wait () from /lib/tls/libpthread.so.0 
#2 0x200000000011d8b0 in pthread_mutex_lock () 
from /lib/tls/libpthread.so.0 
#3 0x200000000005a430 in TCMalloc_ThreadCache::InitModule () at 
src/internal_spinlock.h:125 
#4 0x2000000000060290 in malloc (size=56) at src/tcmalloc.cc:1676 
#5 0x20000000000174b0 in _dl_map_object_deps () from /lib/ld-linux-
ia64.so.2 
#6 0x2000000000352b00 in dl_open_worker () from /lib/tls/libc.so.6.1 
#7 0x2000000000019d90 in _dl_catch_error () from /lib/ld-linux-ia64.so.2 
#8 0x2000000000354800 in _dl_open () from /lib/tls/libc.so.6.1 
#9 0x2000000000357980 in do_dlopen () from /lib/tls/libc.so.6.1 
#10 0x2000000000019d90 in _dl_catch_error () from /lib/ld-linux-ia64.so.2 
#11 0x2000000000357b20 in __libc_dlopen_mode () from /lib/tls/libc.so.6.1 
#12 0x2000000000308c20 in init () from /lib/tls/libc.so.6.1 
#13 0x2000000000124240 in pthread_once () from /lib/tls/libpthread.so.0 
#14 0x2000000000309090 in backtrace () from /lib/tls/libc.so.6.1 
#15 0x20000000003b4aa0 in GetStackTrace (result=0x6000000000044010, 
max_depth=30, skip_count=4) 
at src/stacktrace_generic-inl.h:46 
#16 0x2000000000058eb0 in TCMalloc_PageHeap::GrowHeap 
(this=0x200000000008e578, n=1) at src/tcmalloc.cc:961 
#17 0x20000000000596c0 in TCMalloc_PageHeap::New (this=0x200000000008e578, 
n=1) at src/tcmalloc.cc:811 
#18 0x2000000000059b50 in TCMalloc_Central_FreeList::Populate 
(this=0x20000000000a2468) 
at src/tcmalloc.cc:1523 
#19 0x2000000000059e30 in TCMalloc_Central_FreeList::FetchFromSpansSafe 
(this=0x20000000000a2468) 
at src/tcmalloc.cc:1490 
#20 0x2000000000059f10 in TCMalloc_Central_FreeList::RemoveRange 
(this=0x20000000000a2468, 
start=0x60000fffffffa7b0, end=0x60000fffffffa7b8, N=0x60000fffffffa7c0) at 
src/tcmalloc.cc:1464 
#21 0x200000000005a1a0 in TCMalloc_ThreadCache::FetchFromCentralCache 
(this=0x6000000000004000, cl=24) 
at src/tcmalloc.cc:1622 
#22 0x200000000005f5c0 in realloc (old_ptr=0x0, new_size=256) at 
src/tcmalloc.cc:1600 
#23 0x200000000019b8e0 in __add_to_environ () from /lib/tls/libc.so.6.1 
#24 0x200000000019c080 in setenv () from /lib/tls/libc.so.6.1 
#25 0x2000000000063630 in MallocExtension::Initialize () at 
src/malloc_extension.cc:68 
#26 0x2000000000067cc0 in HeapProfiler::Init () at src/heap-
profiler.cc:978 
#27 0x2000000000067f90 in google_init_module_heapprofile () at src/heap-
profiler.cc:1057 
#28 0x2000000000069780 in global constructors keyed to 
_ZN60FLAG__namespace_do_not_use_directly_use_DECLARE_b\ 
ool_instead31FLAGS_cleanup_old_heap_profilesE () at 
src/base/googleinit.h:40 
#29 0x2000000000076ff0 in std::_Rb_treealue>, std::_Select1st >, 
std::less>, std::allocator > >::insert_unique () 
from ./libtcmalloc.so.0 
#30 0x200000000001a210 in _dl_init_internal () from /lib/ld-linux-
ia64.so.2 
#31 0x2000000000002d90 in _dl_start_user () from /lib/ld-linux-ia64.so.2 


What is the expected output? What do you see instead?

No dead-lock.

What version of the product are you using? On what operating system?

 - Redhat Enterprise Linux v.4 (Update 4)


Please provide any additional information below.

unfortunately, 
o tcmalloc's malloc use backtrace() function. 
o IA64 glibc backtrace() function use dlopen.
  (internaly use libunwind.so)
o and, any platform glibc dlopen use malloc. 

then cause dead-lock(T_T)

I suggest call backtrace() once at constructor like function, not in malloc
().
because backtrace() function use dlopen() only first called.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
1. Run Apache with tcmalloc
2. After a few seconds on a fairly busy site, apache died with the
following in the error_log:

*** glibc detected *** double free or corruption (out): 0x098265a0 ***
*** glibc detected *** free(): invalid pointer: 0x09a08668 ***
*** glibc detected *** double free or corruption (out): 0x09824870 ***
*** glibc detected *** double free or corruption (out): 0x098a30c8 ***
*** glibc detected *** free(): invalid pointer: 0x09824ca8 ***
[Mon Jul 23 23:46:33 2007] [notice] child pid 1462 exit signal Aborted (6)
[Mon Jul 23 23:46:33 2007] [notice] child pid 1465 exit signal Aborted (6)
[Mon Jul 23 23:46:33 2007] [notice] child pid 1469 exit signal Aborted (6)
[Mon Jul 23 23:46:33 2007] [notice] child pid 1514 exit signal Aborted (6)
[Mon Jul 23 23:46:33 2007] [notice] child pid 1518 exit signal Aborted (6)
*** glibc detected *** free(): invalid pointer: 0x09822320 ***
*** glibc detected *** free(): invalid pointer: 0x0980f028 ***
*** glibc detected *** free(): invalid pointer: 0x096d5708 ***
[Mon Jul 23 23:46:34 2007] [notice] child pid 1464 exit signal Aborted (6)
[Mon Jul 23 23:46:34 2007] [notice] child pid 1466 exit signal Aborted (6)
[Mon Jul 23 23:46:34 2007] [notice] child pid 1526 exit signal Aborted (6)
*** glibc detected *** free(): invalid pointer: 0x0983f118 ***
[Mon Jul 23 23:46:35 2007] [notice] child pid 1528 exit signal Aborted (6)
*** glibc detected *** free(): invalid next size (fast): 0x0989ef28 ***
*** glibc detected *** free(): invalid pointer: 0x0985b028 ***
[Mon Jul 23 23:46:37 2007] [notice] child pid 1527 exit signal Aborted (6)
[Mon Jul 23 23:46:37 2007] [notice] child pid 1529 exit signal Aborted (6)
# *** glibc detected *** free(): invalid pointer: 0x096d5a28 ***
*** glibc detected *** free(): invalid pointer: 0x09833e88 ***
*** glibc detected *** free(): invalid pointer: 0x09860ac8 ***
*** glibc detected *** free(): invalid pointer: 0x098c45c8 ***
*** glibc detected *** free(): invalid pointer: 0x0982f2d0 ***
*** glibc detected *** double free or corruption (!prev): 0x099135a0 ***
*** glibc detected *** double free or corruption (out): 0x09824ca8 ***
*** glibc detected *** free(): invalid pointer: 0x09824280 ***
*** glibc detected *** free(): invalid pointer: 0x098e0820 ***
*** glibc detected *** free(): invalid pointer: 0x0982e0f0 ***
*** glibc detected *** free(): invalid pointer: 0x0983b5f0 ***
[Mon Jul 23 23:46:46 2007] [notice] child pid 1531 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1532 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1533 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1534 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1535 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1536 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1537 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1538 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1539 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1540 exit signal Aborted (6)
[Mon Jul 23 23:46:46 2007] [notice] child pid 1542 exit signal Aborted (6)


What is the expected output? What do you see instead?
Apache shouldn't die unexpectedly.

What version of the product are you using? On what operating system?
Centos
2.6.9-42.ELsmp #1 SMP Sat Aug 12 09:39:11 CDT 2006 i686 athlon i386 GNU/Linux

httpd 2.0.52-28 with PHP 4.3.9, APC 3.0.14.


Please provide any additional information below:

httpd executed using LD_PRELOAD=/usr/lib/libtcmalloc.so.0

What steps will reproduce the problem?
1. ./configure
2. make tcmalloc_minimal_unittest tcmalloc_minimal_large_unittest         
    addressmap_unittest atomicops_unittest frag_unittest             
low_level_alloc_unittest markidle_unittest memalign_unittest             
packed_cache_test stacktrace_unittest system_alloc_unittest             
thread_dealloc_unittest

What is the expected output? What do you see instead?

Success is expected.

Instead:

creating markidle_unittest
if g++ -DHAVE_CONFIG_H -I. -I. -I./src  -I./src  -D_THREAD_SAFE  -g -O2 -MT
memalign_unittest-memalign_unittest.o -MD -MP -MF
".deps/memalign_unittest-memalign_unittest.Tpo" -c -o
memalign_unittest-memalign_unittest.o `test -f
'src/tests/memalign_unittest.cc' || echo './'`src/tests/memalign_unittest.cc; \
then mv -f ".deps/memalign_unittest-memalign_unittest.Tpo"
".deps/memalign_unittest-memalign_unittest.Po"; else rm -f
".deps/memalign_unittest-memalign_unittest.Tpo"; exit 1; fi
src/tests/memalign_unittest.cc: In function 'int main(int, char**)':
src/tests/memalign_unittest.cc:165: error: 'getpagesize' was not declared
in this scope
make: *** [memalign_unittest-memalign_unittest.o] Error 1


What version of the product are you using? On what operating system?

0.92 on i386 Mac OS X

Please provide any additional information below.

Followed instructions in the INSTALL for building on OS X.

What steps will reproduce the problem?
1. ./configure
2. make

configure complains:
checking how to access the program counter from a struct ucontext... configure: 
WARNING: Could not find the PC.  
libprofiler will probably not compile!

and compiling then fails:
src/getpc.h: In function 'void* GetPC(const ucontext_t&)':
src/getpc.h:171: error: 'const struct __darwin_ucontext' has no member named 
'PC_FROM_UCONTEXT'

I fixed it on my machine (10.5 Intel) by adding line:
pc_fields="$pc_fields uc_mcontext->__ss.__eip"          # OS X (i386)
to configure.ac, and running autoreconf, ./configure, make

Apparently the include sys/cdefs.h defines __DARWIN_UNIX03, which in turn 
changes some structure definitions. Fix for 
PPC/PPC64 and x86_64 is probably similar (adding uc_mcontext->__ss.__rip and 
uc_mcontext->__ss.__srr0 accessors), 
but I can't confirm it.

Version 0.93 of the google-perftools compiled fine for me on x86_64 linux
using both the latest libunwind snapshot (0.99 alpha, dated 2007-10-18) and
the one mentioned in the perftools documentation (libunwind-snap-070410).

Version 0.94, however, has a compile error.

Attached is my configure/compile log.

What steps will reproduce the problem?
1. Unpack google-perftools-0.93.tar.gz
2. ./configure --prefix=/opt/misc
3. make && make check

What version of the product are you using? On what operating system?

Google Perftools 0.93 (from .tar.gz) on Mac OS X 10.4.10 / MacBook Pro with 
Core 2 Duo / gcc 
version 4.0.1 (Apple Computer, Inc. build 5367)

Please provide any additional information below.

Note that the system has 2 CPU cores, 2 GB of RAM, and was basically idle while 
running the 
tests, i.e. the note "If your system is loaded, the test may spuriously fail." 
should not apply 
(although I did run the tests 4 or 5 times, just to make sure). 

> make check
rm -f maybe_threads_unittest.sh
cp -p ./src/tests/maybe_threads_unittest.sh maybe_threads_unittest.sh
rm -f heap-profiler_unittest.sh
cp -p ./src/tests/heap-profiler_unittest.sh heap-profiler_unittest.sh
rm -f heap-checker_unittest.sh
cp -p ./src/tests/heap-checker_unittest.sh heap-checker_unittest.sh
rm -f heap-checker-death_unittest.sh
cp -p ./src/tests/heap-checker-death_unittest.sh heap-checker-death_unittest.sh
rm -f profiler_unittest.sh
cp -p ./src/tests/profiler_unittest.sh profiler_unittest.sh
make  pprof_unittest
./src/pprof -test
AddressAdd 32-bit tests: 5 passes, 0 failures
AddressAdd 64-bit tests: 10 passes, 0 failures
AddressSub 32-bit tests: 5 passes, 0 failures
AddressSub 64-bit tests: 10 passes, 0 failures
AddressInc 32-bit tests: 5 passes, 0 failures
AddressInc 64-bit tests: 10 passes, 0 failures
PASS
make  check-TESTS
rm -f maybe_threads_unittest.sh
cp -p ./src/tests/maybe_threads_unittest.sh maybe_threads_unittest.sh
rm -f heap-profiler_unittest.sh
cp -p ./src/tests/heap-profiler_unittest.sh heap-profiler_unittest.sh
rm -f heap-checker_unittest.sh
cp -p ./src/tests/heap-checker_unittest.sh heap-checker_unittest.sh
rm -f heap-checker-death_unittest.sh
cp -p ./src/tests/heap-checker-death_unittest.sh heap-checker-death_unittest.sh
rm -f profiler_unittest.sh
cp -p ./src/tests/profiler_unittest.sh profiler_unittest.sh
PASS
PASS: low_level_alloc_unittest
PASS
PASS: atomicops_unittest
Obtained 10 stack frames.
PASS
PASS: stacktrace_unittest
Testing empty allocation
Sanity-testing all the memory allocation functions
Testing large allocation
Testing calloc
Testing operator new(nothrow).
Testing operator new[](nothrow).
Testing operator new.
Testing operator new[].
Testing threaded allocation/deallocation (10 threads)
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: free
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: free
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: update
  Test 50000 out of 50000: allocate
Testing huge allocations
Testing out of memory
PASS
PASS: tcmalloc_unittest
Testing empty allocation
Sanity-testing all the memory allocation functions
Testing large allocation
Testing calloc
Testing operator new(nothrow).
Testing operator new[](nothrow).
Testing operator new.
Testing operator new[].
Testing threaded allocation/deallocation (10 threads)
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: free
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: free
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: update
  Test 50000 out of 50000: allocate
Testing huge allocations
Testing out of memory
PASS
PASS: tcmalloc_minimal_unittest
Testing empty allocation
Sanity-testing all the memory allocation functions
Testing large allocation
Testing calloc
Testing operator new(nothrow).
Testing operator new[](nothrow).
Testing operator new.
Testing operator new[].
Testing threaded allocation/deallocation (10 threads)
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: free
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: free
  Test 50000 out of 50000: allocate
  Test 50000 out of 50000: free
  Test 50000 out of 50000: update
  Test 50000 out of 50000: allocate
Testing huge allocations
Testing out of memory
PASS
PASS: tcmalloc_both_unittest
Test malloc(0) x 1024
Test small malloc
Test malloc(0 - N)
Test malloc(0 - 1048576 - N)
Test malloc(max/2 +- N)
PASS
PASS: tcmalloc_large_unittest
Test malloc(0) x 1024
Test small malloc
Test malloc(0 - N)
Test malloc(0 - 1048576 - N)
Test malloc(max/2 +- N)
PASS
PASS: tcmalloc_minimal_large_unittest
PASS
PASS: maybe_threads_unittest.sh
PASS
PASS: system_alloc_unittest
PASS
PASS: packed_cache_test
getproperty:  171.8 ns/call
getproperty:  171.7 ns/call
getproperty:  171.8 ns/call
getproperty:  171.8 ns/call
getproperty:  171.7 ns/call
PASS
PASS: frag_unittest
Original usage: 712
Post allocation: 1843168
Post idle: 0
PASS
PASS: markidle_unittest
PASS
PASS: memalign_unittest
Iteration: 200 of 1000
------------------------------------------------
class   1 [        8 bytes ] :      510 objs;   0.0 MB;   0.0 cum MB
class   2 [       16 bytes ] :      254 objs;   0.0 MB;   0.0 cum MB
class  36 [     1024 bytes ] :     1020 objs;   1.0 MB;   1.0 cum MB
class  47 [     4096 bytes ] :        1 objs;   0.0 MB;   1.0 cum MB
------------------------------------------------
PageHeap: 2 sizes;    1.0 MB free
------------------------------------------------
     1 pages *      6 spans ~    0.0 MB;    0.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
   248 pages *      1 spans ~    1.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
Normal large spans:
Unmapped large spans:
>255   large *      0 spans ~    0.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    
0.0 MB cum
------------------------------------------------
MALLOC:      3145728 Heap size
MALLOC:      1048624 Bytes in use by application
MALLOC:      1040384 Bytes free in page heap
MALLOC:         7432 Bytes free in central cache
MALLOC:       786432 Bytes free in transfer cache
MALLOC:       262856 Bytes free in thread caches
MALLOC:          268 Spans in use
MALLOC:            1 Thread heaps in use
MALLOC:       524288 Metadata allocated
------------------------------------------------

Iteration: 400 of 1000
------------------------------------------------
class   1 [        8 bytes ] :      510 objs;   0.0 MB;   0.0 cum MB
class   2 [       16 bytes ] :      254 objs;   0.0 MB;   0.0 cum MB
class  36 [     1024 bytes ] :     1020 objs;   1.0 MB;   1.0 cum MB
class  47 [     4096 bytes ] :        1 objs;   0.0 MB;   1.0 cum MB
------------------------------------------------
PageHeap: 2 sizes;    1.0 MB free
------------------------------------------------
     1 pages *      6 spans ~    0.0 MB;    0.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
   248 pages *      1 spans ~    1.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
Normal large spans:
Unmapped large spans:
>255   large *      0 spans ~    0.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    
0.0 MB cum
------------------------------------------------
MALLOC:      3145728 Heap size
MALLOC:      1048624 Bytes in use by application
MALLOC:      1040384 Bytes free in page heap
MALLOC:         7432 Bytes free in central cache
MALLOC:       786432 Bytes free in transfer cache
MALLOC:       262856 Bytes free in thread caches
MALLOC:          268 Spans in use
MALLOC:            1 Thread heaps in use
MALLOC:       524288 Metadata allocated
------------------------------------------------

Iteration: 600 of 1000
------------------------------------------------
class   1 [        8 bytes ] :      510 objs;   0.0 MB;   0.0 cum MB
class   2 [       16 bytes ] :      254 objs;   0.0 MB;   0.0 cum MB
class  36 [     1024 bytes ] :     1020 objs;   1.0 MB;   1.0 cum MB
class  47 [     4096 bytes ] :        1 objs;   0.0 MB;   1.0 cum MB
------------------------------------------------
PageHeap: 2 sizes;    1.0 MB free
------------------------------------------------
     1 pages *      6 spans ~    0.0 MB;    0.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
   248 pages *      1 spans ~    1.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
Normal large spans:
Unmapped large spans:
>255   large *      0 spans ~    0.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    
0.0 MB cum
------------------------------------------------
MALLOC:      3145728 Heap size
MALLOC:      1048624 Bytes in use by application
MALLOC:      1040384 Bytes free in page heap
MALLOC:         7432 Bytes free in central cache
MALLOC:       786432 Bytes free in transfer cache
MALLOC:       262856 Bytes free in thread caches
MALLOC:          268 Spans in use
MALLOC:            1 Thread heaps in use
MALLOC:       524288 Metadata allocated
------------------------------------------------

Iteration: 800 of 1000
------------------------------------------------
class   1 [        8 bytes ] :      510 objs;   0.0 MB;   0.0 cum MB
class   2 [       16 bytes ] :      254 objs;   0.0 MB;   0.0 cum MB
class  36 [     1024 bytes ] :     1020 objs;   1.0 MB;   1.0 cum MB
class  47 [     4096 bytes ] :        1 objs;   0.0 MB;   1.0 cum MB
------------------------------------------------
PageHeap: 2 sizes;    1.0 MB free
------------------------------------------------
     1 pages *      6 spans ~    0.0 MB;    0.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
   248 pages *      1 spans ~    1.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
Normal large spans:
Unmapped large spans:
>255   large *      0 spans ~    0.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    
0.0 MB cum
------------------------------------------------
MALLOC:      3145728 Heap size
MALLOC:      1048624 Bytes in use by application
MALLOC:      1040384 Bytes free in page heap
MALLOC:         7432 Bytes free in central cache
MALLOC:       786432 Bytes free in transfer cache
MALLOC:       262856 Bytes free in thread caches
MALLOC:          268 Spans in use
MALLOC:            1 Thread heaps in use
MALLOC:       524288 Metadata allocated
------------------------------------------------

Iteration: 1000 of 1000
------------------------------------------------
class   1 [        8 bytes ] :      510 objs;   0.0 MB;   0.0 cum MB
class   2 [       16 bytes ] :      254 objs;   0.0 MB;   0.0 cum MB
class  36 [     1024 bytes ] :     1020 objs;   1.0 MB;   1.0 cum MB
class  47 [     4096 bytes ] :        1 objs;   0.0 MB;   1.0 cum MB
------------------------------------------------
PageHeap: 2 sizes;    1.0 MB free
------------------------------------------------
     1 pages *      6 spans ~    0.0 MB;    0.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
   248 pages *      1 spans ~    1.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    0.0 MB cum
Normal large spans:
Unmapped large spans:
>255   large *      0 spans ~    0.0 MB;    1.0 MB cum; unmapped:    0.0 MB;    
0.0 MB cum
------------------------------------------------
MALLOC:      3145728 Heap size
MALLOC:      1048624 Bytes in use by application
MALLOC:      1040384 Bytes free in page heap
MALLOC:         7432 Bytes free in central cache
MALLOC:       786432 Bytes free in transfer cache
MALLOC:       262856 Bytes free in thread caches
MALLOC:          268 Spans in use
MALLOC:            1 Thread heaps in use
MALLOC:       524288 Metadata allocated
------------------------------------------------

PASS
PASS: thread_dealloc_unittest
PASS
PASS: addressmap_unittest
PASS
PASS: heap-profiler_unittest.sh
Testing ./heap-checker_unittest with HEAPCHECK= ... OK
Testing ./heap-checker_unittest with HEAPCHECK=local ... 
./heap-checker_unittest.sh: line 83: 
26996 Abort trap              $HEAP_CHECKER >$TMPDIR/output 2>&1
FAILED
Output from the failed run:
----
Can not start so late. You have to enable heap checking with HEAPCHECK=<mode>.
----
FAIL: heap-checker_unittest.sh
Testing ./heap-checker_unittest with HEAPCHECK= ... FAIL
Wrong exit code: expected: '0'; actual: 1
Output did not match '^PASS$'
Output from failed run:

---
Starting tracking the heap
Check failed: regions_ != NULL: 

---
FAIL: heap-checker-death_unittest.sh
PASS
PASS: getpc_test

>>> WARNING <<<
This test looks at timing information to determine correctness.
If your system is loaded, the test may spuriously fail.
If the test does fail with an 'Actual times' error, try running again.

PROFILE: interrupts/evictions/bytes = 0/0/32
PROFILE: interrupts/evictions/bytes = 1/0/76
Removing 0xffffffff from all stack traces.
Removing 0x9000fecd from all stack traces.
Removing 0x90022cb8 from all stack traces.
Removing test_main_thread from all stack traces.
Removing _main from all stack traces.
Removing __start from all stack traces.
Removing start from all stack traces.
Removing __Z41__static_initialization_and_destruction_0ii.eh from all stack 
traces.
expr: syntax error
expr: syntax error

>>> profile on 
/Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler1_unittest 
vs /Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler1_unittest 
with 
multiplier 2 failed:
Actual times (in profiling units) were '' vs. ''

PROFILE: interrupts/evictions/bytes = 27/0/860
PROFILE: interrupts/evictions/bytes = 32/0/1052
Removing 0xffffffff from all stack traces.
Removing 0xffffffff from all stack traces.
PROFILE: interrupts/evictions/bytes = 0/0/32
PROFILE: interrupts/evictions/bytes = 49/0/1392
Removing 0xffffffff from all stack traces.
expr: syntax error

>>> profile on 
/Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler2_unittest 
vs /Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler2_unittest 
with 
multiplier 2 failed:
Actual times (in profiling units) were '' vs. '21'

PROFILE: interrupts/evictions/bytes = 79/8/2580
PROFILE: interrupts/evictions/bytes = 0/0/32
Removing 0xffffffff from all stack traces.
expr: syntax error

>>> profile on 
/Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler3_unittest 
vs /Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler3_unittest 
with 
multiplier 2 failed:
Actual times (in profiling units) were '4' vs. ''

PROFILE: interrupts/evictions/bytes = 29/0/1108
PROFILE: interrupts/evictions/bytes = 0/0/32
Removing 0xffffffff from all stack traces.
expr: syntax error

>>> profile on 
/Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler3_unittest 
vs /Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler3_unittest 
with 
multiplier 2 failed:
Actual times (in profiling units) were '2' vs. ''

PROFILE: interrupts/evictions/bytes = 50/1/1828
PROFILE: interrupts/evictions/bytes = 40/0/1128
Removing 0xffffffff from all stack traces.
Removing 0xffffffff from all stack traces.
PROFILE: interrupts/evictions/bytes = 24/0/928
PROFILE: interrupts/evictions/bytes = 0/0/32
Removing 0xffffffff from all stack traces.
expr: syntax error

>>> profile on 
/Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler4_unittest 
vs /Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler4_unittest 
with 
multiplier 2 failed:
Actual times (in profiling units) were '0' vs. ''

PROFILE: interrupts/evictions/bytes = 52/0/2052
Removing 0xffffffff from all stack traces.

>>> profile on 
/Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler4_unittest 
vs /Users/colin/Exclude/Download/google-perftools-0.93/.libs/profiler4_unittest 
with 
multiplier 2 failed:
Actual times (in profiling units) were '0' vs. ''

PROFILE: interrupts/evictions/bytes = 31/0/1260
PROFILE: interrupts/evictions/bytes = 16/3/600
PROFILE: interrupts/evictions/bytes = 7/0/296
Tests finished with 6 failures
FAIL: profiler_unittest.sh
======================================
3 of 21 tests failed
Please report to [email protected]
======================================
make[1]: *** [check-TESTS] Error 1
make: *** [check-am] Error 2

When trying to build the google-perftools on MinGW32 the build fails.

The problem is that when building with make, it is assumed that is is a 
Posix target, but it is a Win32 target. As a result it is required to have 
Visual Studio to build on Windows.

To reproduce the error: (On a Windows platform.)

1.  Install MinGW & MSYS.

2.  tar -xzvf google-perftools-0.93.tar.gz

3.  ./configure 

4.  make

This requires only a change in the buildsystem, since the code for Windows 
is already there.

What steps will reproduce the problem?
1. Compile in VC7.1
2.
3.

What is the expected output? What do you see instead?
\GoogleCode\perftools\src\malloc_extension.cc(104) : warning C4318: passing
constant zero as the length to memset

What version of the product are you using? On what operating system?
VC7.1.3088 in Windows 2003

Please provide any additional information below.
It should be "memset(histogram, 0, sizeof(histogram));"

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

See patch from [email protected], at
http://google-perftools.googlegroups.com/web/google-perftools-0.94.1.ppc.patch?g
da=k9bft1IAAACubrlYz6X6f2r_QSIc5WKIP3FyvVAXIQ9N70rJj7w7MWG1qiJ7UbTIup-M2XPURDR0O
dCHCKqS2f7o1Lzcc8Kg4jvJEVA5r4WYNVZfjSxuln7gCK2zepjMSjyreBgvHJk

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

What steps will reproduce the problem?
I don't know can it be reproduced, but I often see call-graph as in 
attachment. But disassembly gives following results:
ROUTINE ====================== 
VZL::VZLChannelEndLocalPrototype::recvMessage(VZL::VZLMessage*&)
     0   5429 Total samples (flat / cumulative)
     .      . ControlLocal.cpp:115 009720c0: push   %ebp
     .      . ControlLocal.cpp:115 009720c1: mov    %esp,%ebp
     .      . ControlLocal.cpp:115 009720c3: push   %ebx
     .      . ControlLocal.cpp:115 009720c4: sub    $0x4,%esp
     .      . ControlLocal.cpp:115 009720c7: call   2e0cc 
<_ZN3VZL27VZLChannelEndLocalPrototype11recvMessageERPNS_10VZLMessageE+0xc>
     .      . ControlLocal.cpp:115 009720cc: pop    %ebx
     .      . ControlLocal.cpp:115 009720cd: add    $0xdc84,%ebx
     .      . ControlLocal.cpp:117 009720d3: sub    $0x8,%esp
     .      . ControlLocal.cpp:117 009720d6: pushl  0xc(%ebp)
     .      . ControlLocal.cpp:117 009720d9: pushl  0x8(%ebp)
     .      . ControlLocal.cpp:117 009720dc: call   1e264 
<_ZN3VZL18VZLIOPipePrototype11readMessageERPNS_10VZLMessageE@plt>
     .   5429 ControlLocal.cpp:117 009720e1: add    $0x10,%esp
     .      . ControlLocal.cpp:118 009720e4: mov    0xfffffffc(%ebp),%ebx
     .      . ControlLocal.cpp:118 009720e7: leave
     .      . ControlLocal.cpp:118 009720e8: ret
     .      . ControlLocal.cpp:118 009720e9: nop
(this is just this->VirtualMethod() call)
It seems that profiling samples are assigned to wrong address.

What version of the product are you using? On what operating system?
I compiled google-perftools-0.92 and my program with gcc-32 on Fedora 
Core 7.
./configure --prefix=/usr/local CC=gcc32 CXX=g++32 --enable-debug


Please provide any additional information below.

What steps will reproduce the problem?
1. Run program to profile
LD_PRELOAD=/opt/google-perftools/lib/libtcmalloc.so.0  
HEAPPROFILE=/root/myprog.hprof HEAP_PROFILE_MMAP=true 
HEAP_PROFILE_MMAP_LOG=true myprog
2. It writes to output and locks.
Starting tracking the heap
mmap(start=0x0, len=69632, prot=0x3, flags=0x22, fd=-1, offset=0x0) = 
0x2aaab08b8000

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
google-perftools-0.91 compiled from sources with gcc-3.2 on FC6 x86_64 
arch.

Please provide any additional information below.
The first deadlock appeared when heap profiler calls HeapProfilerStart 
from HeapProfilerInit with initialized mmap hooks and heap_lock held.
After I moved mmap hooks initialization to the end of HeapProfilerInit:
  HeapProfileTable::CleanupOldProfiles(fname);

  HeapProfilerStart(fname);
  if (FLAGS_mmap_profile || FLAGS_mmap_log) {
    MallocHook::SetMmapHook(MmapHook);
    MallocHook::SetMunmapHook(MunmapHook);
  }
Second deadlock appeared with following call stack (some functions seems 
to be inlined, though I compiled all programs with -g and without any -O 
flags):
#0  0x00000034da98f7a2 in __nanosleep_nocancel () 
from /lib64/tls/libc.so.6
#1  0x00002aaaaaafd57a in 
HeapLeakCheckerGlobalPrePost::~HeapLeakCheckerGlobalPrePost () at 
src/malloc_hook.cc:294
#2  0x00002aaaaaadc263 in SpinLock::Lock (this=0x2aaaaad2dac0) at 
VZLCounter.h:129
#3  0x00002aaaaaae7dc2 in RecordAlloc (ptr=0x2aaab08b8000, bytes=69632, 
skip_count=0) at src/heap-profiler.cc:195
#4  0x00002aaaaaae803a in MmapHook (result=0x2aaab08b8000, start=0x0, 
size=69632, prot=3, flags=34, fd=-1, offset=0)
    at src/heap-profiler.cc:267
#5  0x00002aaaaaae208d in MallocHook::InvokeMmapHook 
(result=0x2aaab08b8000, start=0x0, size=69632, protection=3, flags=34,
    fd=-1, offset=0) at src/google/malloc_hook.h:100
#6  0x00002aaaaaafe141 in virtual thunk to 
VZL::VZLForkableRefCounter::~VZLForkableRefCounter$delete() () at 
VZLCounter.h:129
#7  0x00002aaaaaafe5e0 in LowLevelAlloc::Alloc (request=65560, 
arena=0x2aaaadf30020) at VZLCounter.h:129
#8  0x00002aaaaaae7bb8 in ProfilerMalloc (bytes=65560) at 
src/heap-profiler.cc:110
#9  0x00002aaaaaaea5c9 in MallocHook::SetDeleteHook () at 
src/heap-checker.cc:367
#10 0x00002aaaaaaea319 in MallocHook::SetDeleteHook () at 
src/heap-checker.cc:367
#11 0x00002aaaaaae9cd0 in MallocHook::SetDeleteHook () 
at /usr/include/c++/3.2.3/bits/basic_string.h:955
#12 0x00002aaaaaae913a in MallocHook::SetDeleteHook () 
at /usr/include/c++/3.2.3/bits/basic_string.h:955
#13 0x00002aaaaaae7de8 in RecordAlloc (ptr=0x1c7021d8, bytes=1, 
skip_count=0) at src/heap-profiler.cc:197
#14 0x00002aaaaaae7f4f in NewHook (ptr=0x1c7021d8, size=1) at 
src/heap-profiler.cc:240
#15 0x00002aaaaaae0e11 in MallocHook::InvokeNewHook (p=0x1c7021d8, s=1) 
at src/google/malloc_hook.h:62
#16 0x00002aaaaaafd8be in malloc (size=1) at src/tcmalloc.cc:2785
#17 0x00002aaaaaae1323 in TCMallocGuard (this=0x2aaaaad2d860) at 
src/tcmalloc.cc:2510
#18 0x00002aaaaaae00cc in __static_initialization_and_destruction_0 
(__initialize_p=1, __priority=65535) at src/tcmalloc.cc:2525
#19 0x00002aaaaaae07f9 in global constructors keyed to 
_ZN61FLAG__namespace_do_not_use_directly_use_DECLARE_int64_instead31FLAGS_tcmall
oc_sample_parameterE 
() at src/tcmalloc.cc:572
#20 0x00002aaaaaafd886 in 
HeapLeakCheckerGlobalPrePost::~HeapLeakCheckerGlobalPrePost () at 
src/malloc_hook.cc:294

I suppose RecordAlloc should be reentrant or there should be some flag to 
suspend tcmalloc's allocation logging.

In the CPU profiler documentation:
1. It would be nice to have the LD_PRELOAD command specified, as in heap
profiling documentation, for example (e.g. env
LD_PRELOAD="/usr/local/lib/libprofiler.so")
2. Specify the default value of CPUPROFILE_FREQUENCY, if not specified by
the user.

What steps will reproduce the problem?
1. Go to Sourceforge pages
2. Look at the open bug reports
3. Realize that none of them is assigned or answered
4. Start wondering (see Summary)

What is the expected output? What do you see instead?
EO: Bugs fixed or requests answered.
SI: Reports are not even assigned to anyone.

What version of the product are you using? On what operating system?
N/A

Please provide any additional information below.
Perhaps You are waiting for volunteers?  Perhaps you do not look at the
SourceForge pages anymore, and nobody copied the bug reports?  Let us know! :-)

What steps will reproduce the problem?
1. Go to http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools
2. Click the "CPU profiler" link
(http://google-perftools.googlecode.com/svn/trunk/doc/cpu_profiler.html)
3. Enjoy the 404

Related to issue 24, one more test link problem came out in 0.94.1.

Attached the patch to resolve it.

Maybe google could implement this... :)

Using google-perftools 0.94.1 with libunwind-snap-070410 on 64 bit, Centos
5.0, I occasionally get this deadlock when doing cpu profiling:

#0  0x0000003e0a80d401 in __nanosleep_nocancel () from /lib64/libpthread.so.0
#1  0x0000000000f2f0fb in SpinLock::SlowLock ()
#2  0x0000000000f4290a in GetStackTrace ()
#3  0x0000000000f2cc9d in CpuProfiler::prof_handler ()
#4  <signal handler called>
#5  0x0000000000f428a7 in GetStackTrace ()
#6  0x0000000000f30792 in DoSampledAllocation ()
#7  0x0000000000fb02a7 in operator new ()

The bug is clear from reading the code - if the SIGPROF fires when we're
inside the mutex'd region of GetStackTrace called by DoSampledAllocation(),
then the deadlock happens.

I don't actually understand why that mutex is even needed.  The comment
says libunwind can call sbrk/mmap/malloc, but I thought the whole point of
using libunwind is it doesn't do any allocation.  I couldn't find any
allocation in the unwind code, so I took out the mutex, and now everything
works.