aoyoo / gperftools Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/gperftools
License: BSD 3-Clause "New" or "Revised" License
Automatically exported from code.google.com/p/gperftools
License: BSD 3-Clause "New" or "Revised" License
IMPORTANT NOTE FOR 64-BIT USERS ------------------------------- There are known issues with some perftools functionality on x86_64 systems. See 64-BIT ISSUES, below. TCMALLOC -------- Just link in -ltcmalloc or -ltcmalloc_minimal to get the advantages of tcmalloc -- a replacement for malloc and new. See below for some environment variables you can use with tcmalloc, as well. tcmalloc functionality is available on all systems we've tested; see INSTALL for more details. See README_windows.txt for instructions on using tcmalloc on Windows. NOTE: When compiling with programs with gcc, that you plan to link with libtcmalloc, it's safest to pass in the flags -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free when compiling. gcc makes some optimizations assuming it is using its own, built-in malloc; that assumption obviously isn't true with tcmalloc. In practice, we haven't seen any problems with this, but the expected risk is highest for users who register their own malloc hooks with tcmalloc (using gperftools/malloc_hook.h). The risk is lowest for folks who use tcmalloc_minimal (or, of course, who pass in the above flags :-) ). HEAP PROFILER ------------- See doc/heap-profiler.html for information about how to use tcmalloc's heap profiler and analyze its output. As a quick-start, do the following after installing this package: 1) Link your executable with -ltcmalloc 2) Run your executable with the HEAPPROFILE environment var set: $ HEAPPROFILE=/tmp/heapprof <path/to/binary> [binary args] 3) Run pprof to analyze the heap usage $ pprof <path/to/binary> /tmp/heapprof.0045.heap # run 'ls' to see options $ pprof --gv <path/to/binary> /tmp/heapprof.0045.heap You can also use LD_PRELOAD to heap-profile an executable that you didn't compile. There are other environment variables, besides HEAPPROFILE, you can set to adjust the heap-profiler behavior; c.f. "ENVIRONMENT VARIABLES" below. The heap profiler is available on all unix-based systems we've tested; see INSTALL for more details. It is not currently available on Windows. HEAP CHECKER ------------ See doc/heap-checker.html for information about how to use tcmalloc's heap checker. In order to catch all heap leaks, tcmalloc must be linked *last* into your executable. The heap checker may mischaracterize some memory accesses in libraries listed after it on the link line. For instance, it may report these libraries as leaking memory when they're not. (See the source code for more details.) Here's a quick-start for how to use: As a quick-start, do the following after installing this package: 1) Link your executable with -ltcmalloc 2) Run your executable with the HEAPCHECK environment var set: $ HEAPCHECK=1 <path/to/binary> [binary args] Other values for HEAPCHECK: normal (equivalent to "1"), strict, draconian You can also use LD_PRELOAD to heap-check an executable that you didn't compile. The heap checker is only available on Linux at this time; see INSTALL for more details. CPU PROFILER ------------ See doc/cpu-profiler.html for information about how to use the CPU profiler and analyze its output. As a quick-start, do the following after installing this package: 1) Link your executable with -lprofiler 2) Run your executable with the CPUPROFILE environment var set: $ CPUPROFILE=/tmp/prof.out <path/to/binary> [binary args] 3) Run pprof to analyze the CPU usage $ pprof <path/to/binary> /tmp/prof.out # -pg-like text output $ pprof --gv <path/to/binary> /tmp/prof.out # really cool graphical output There are other environment variables, besides CPUPROFILE, you can set to adjust the cpu-profiler behavior; cf "ENVIRONMENT VARIABLES" below. The CPU profiler is available on all unix-based systems we've tested; see INSTALL for more details. It is not currently available on Windows. NOTE: CPU profiling doesn't work after fork (unless you immediately do an exec()-like call afterwards). Furthermore, if you do fork, and the child calls exit(), it may corrupt the profile data. You can use _exit() to work around this. We hope to have a fix for both problems in the next release of perftools (hopefully perftools 1.2). EVERYTHING IN ONE ----------------- If you want the CPU profiler, heap profiler, and heap leak-checker to all be available for your application, you can do: gcc -o myapp ... -lprofiler -ltcmalloc However, if you have a reason to use the static versions of the library, this two-library linking won't work: gcc -o myapp ... /usr/lib/libprofiler.a /usr/lib/libtcmalloc.a # errors! Instead, use the special libtcmalloc_and_profiler library, which we make for just this purpose: gcc -o myapp ... /usr/lib/libtcmalloc_and_profiler.a CONFIGURATION OPTIONS --------------------- For advanced users, there are several flags you can pass to './configure' that tweak tcmalloc performace. (These are in addition to the environment variables you can set at runtime to affect tcmalloc, described below.) See the INSTALL file for details. ENVIRONMENT VARIABLES --------------------- The cpu profiler, heap checker, and heap profiler will lie dormant, using no memory or CPU, until you turn them on. (Thus, there's no harm in linking -lprofiler into every application, and also -ltcmalloc assuming you're ok using the non-libc malloc library.) The easiest way to turn them on is by setting the appropriate environment variables. We have several variables that let you enable/disable features as well as tweak parameters. Here are some of the most important variables: HEAPPROFILE=<pre> -- turns on heap profiling and dumps data using this prefix HEAPCHECK=<type> -- turns on heap checking with strictness 'type' CPUPROFILE=<file> -- turns on cpu profiling and dumps data to this file. PROFILESELECTED=1 -- if set, cpu-profiler will only profile regions of code surrounded with ProfilerEnable()/ProfilerDisable(). CPUPROFILE_FREQUENCY=x-- how many interrupts/second the cpu-profiler samples. TCMALLOC_DEBUG=<level> -- the higher level, the more messages malloc emits MALLOCSTATS=<level> -- prints memory-use stats at program-exit For a full list of variables, see the documentation pages: doc/cpuprofile.html doc/heapprofile.html doc/heap_checker.html COMPILING ON NON-LINUX SYSTEMS ------------------------------ Perftools was developed and tested on x86 Linux systems, and it works in its full generality only on those systems. However, we've successfully ported much of the tcmalloc library to FreeBSD, Solaris x86, and Darwin (Mac OS X) x86 and ppc; and we've ported the basic functionality in tcmalloc_minimal to Windows. See INSTALL for details. See README_windows.txt for details on the Windows port. PERFORMANCE ----------- If you're interested in some third-party comparisons of tcmalloc to other malloc libraries, here are a few web pages that have been brought to our attention. The first discusses the effect of using various malloc libraries on OpenLDAP. The second compares tcmalloc to win32's malloc. http://www.highlandsun.com/hyc/malloc/ http://gaiacrtn.free.fr/articles/win32perftools.html It's possible to build tcmalloc in a way that trades off faster performance (particularly for deletes) at the cost of more memory fragmentation (that is, more unusable memory on your system). See the INSTALL file for details. OLD SYSTEM ISSUES ----------------- When compiling perftools on some old systems, like RedHat 8, you may get an error like this: ___tls_get_addr: symbol not found This means that you have a system where some parts are updated enough to support Thread Local Storage, but others are not. The perftools configure script can't always detect this kind of case, leading to that error. To fix it, just comment out (or delete) the line #define HAVE_TLS 1 in your config.h file before building. 64-BIT ISSUES ------------- There are two issues that can cause program hangs or crashes on x86_64 64-bit systems, which use the libunwind library to get stack-traces. Neither issue should affect the core tcmalloc library; they both affect the perftools tools such as cpu-profiler, heap-checker, and heap-profiler. 1) Some libc's -- at least glibc 2.4 on x86_64 -- have a bug where the libc function dl_iterate_phdr() acquires its locks in the wrong order. This bug should not affect tcmalloc, but may cause occasional deadlock with the cpu-profiler, heap-profiler, and heap-checker. Its likeliness increases the more dlopen() commands an executable has. Most executables don't have any, though several library routines like getgrgid() call dlopen() behind the scenes. 2) On x86-64 64-bit systems, while tcmalloc itself works fine, the cpu-profiler tool is unreliable: it will sometimes work, but sometimes cause a segfault. I'll explain the problem first, and then some workarounds. Note that this only affects the cpu-profiler, which is a gperftools feature you must turn on manually by setting the CPUPROFILE environment variable. If you do not turn on cpu-profiling, you shouldn't see any crashes due to perftools. The gory details: The underlying problem is in the backtrace() function, which is a built-in function in libc. Backtracing is fairly straightforward in the normal case, but can run into problems when having to backtrace across a signal frame. Unfortunately, the cpu-profiler uses signals in order to register a profiling event, so every backtrace that the profiler does crosses a signal frame. In our experience, the only time there is trouble is when the signal fires in the middle of pthread_mutex_lock. pthread_mutex_lock is called quite a bit from system libraries, particularly at program startup and when creating a new thread. The solution: The dwarf debugging format has support for 'cfi annotations', which make it easy to recognize a signal frame. Some OS distributions, such as Fedora and gentoo 2007.0, already have added cfi annotations to their libc. A future version of libunwind should recognize these annotations; these systems should not see any crashses. Workarounds: If you see problems with crashes when running the cpu-profiler, consider inserting ProfilerStart()/ProfilerStop() into your code, rather than setting CPUPROFILE. This will profile only those sections of the codebase. Though we haven't done much testing, in theory this should reduce the chance of crashes by limiting the signal generation to only a small part of the codebase. Ideally, you would not use ProfilerStart()/ProfilerStop() around code that spawns new threads, or is otherwise likely to cause a call to pthread_mutex_lock! --- 17 May 2011
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]
======================================
Original issue reported on code.google.com by [email protected]
on 8 Feb 2008 at 8:02
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.
Original issue reported on code.google.com by [email protected]
on 8 Oct 2007 at 4:15
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.
Original issue reported on code.google.com by [email protected]
on 8 Jan 2008 at 6:59
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.
Original issue reported on code.google.com by [email protected]
on 18 Jun 2007 at 3:50
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));"
Original issue reported on code.google.com by [email protected]
on 5 Aug 2007 at 6:45
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.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2008 at 10:07
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 17 May 2007 at 12:49
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 21 Mar 2007 at 1:44
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
Original issue reported on code.google.com by [email protected]
on 10 May 2007 at 2:44
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
Original issue reported on code.google.com by [email protected]
on 26 May 2007 at 5:39
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.
Original issue reported on code.google.com by [email protected]
on 16 Aug 2007 at 10:48
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 28 Jul 2007 at 8:34
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
Original issue reported on code.google.com by [email protected]
on 23 Mar 2008 at 1:26
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"
Original issue reported on code.google.com by [email protected]
on 4 Mar 2008 at 10:57
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.
Original issue reported on code.google.com by [email protected]
on 11 Dec 2007 at 8:39
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.
Original issue reported on code.google.com by [email protected]
on 13 Mar 2007 at 7:00
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.
Original issue reported on code.google.com by [email protected]
on 15 Jun 2007 at 11:33
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 8 Oct 2007 at 12:43
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.
Original issue reported on code.google.com by [email protected]
on 26 Feb 2008 at 4:52
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.
Original issue reported on code.google.com by [email protected]
on 26 Jul 2007 at 7:52
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.
Original issue reported on code.google.com by [email protected]
on 3 Dec 2007 at 4:58
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 20 Sep 2006 at 8:43
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.
Original issue reported on code.google.com by [email protected]
on 10 Jan 2007 at 1:52
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.
Original issue reported on code.google.com by [email protected]
on 11 Oct 2007 at 9:13
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
Original issue reported on code.google.com by [email protected]
on 21 Dec 2007 at 3:37
(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
Original issue reported on code.google.com by [email protected]
on 17 Apr 2007 at 12:32
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.
Original issue reported on code.google.com by [email protected]
on 15 Feb 2008 at 10:26
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.
Original issue reported on code.google.com by [email protected]
on 24 Nov 2007 at 2:00
Maybe google could implement this... :)
Original issue reported on code.google.com by [email protected]
on 6 Oct 2006 at 4:26
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 22 Jul 2007 at 7:01
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
Original issue reported on code.google.com by [email protected]
on 24 Jul 2007 at 5:02
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.
Original issue reported on code.google.com by [email protected]
on 4 Mar 2007 at 3:21
Attachments:
32bit rpm is available, could not find it for 64 bit. It will be useful to
have 64bit rpm in downloads section.
Original issue reported on code.google.com by [email protected]
on 6 Feb 2008 at 11:32
Related to issue 24, one more test link problem came out in 0.94.1.
Attached the patch to resolve it.
Original issue reported on code.google.com by [email protected]
on 4 Jan 2008 at 3:59
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 23 May 2007 at 2:14
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.
Original issue reported on code.google.com by [email protected]
on 21 Nov 2007 at 8:50
Easy to fix though, just a few new includes, nothing that breaks backwards
compatibility with older gcc.
Patch attached.
Original issue reported on code.google.com by [email protected]
on 4 Jan 2008 at 4:24
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 16 Aug 2006 at 4:24
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.
Original issue reported on code.google.com by [email protected]
on 4 Apr 2007 at 3:02
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.
Original issue reported on code.google.com by [email protected]
on 3 May 2007 at 8:46
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
Original issue reported on code.google.com by [email protected]
on 30 Apr 2007 at 8:30
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)
Original issue reported on code.google.com by [email protected]
on 11 Mar 2008 at 1:12
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.
Original issue reported on code.google.com by [email protected]
on 27 Mar 2007 at 1:47
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.
Original issue reported on code.google.com by [email protected]
on 21 Nov 2007 at 8:21
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.
Original issue reported on code.google.com by [email protected]
on 5 Aug 2007 at 7:18
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++.
Original issue reported on code.google.com by [email protected]
on 14 Dec 2007 at 6:47
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! :-)
Original issue reported on code.google.com by [email protected]
on 2 Oct 2006 at 9:38
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.
Original issue reported on code.google.com by [email protected]
on 21 Mar 2008 at 10:44
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.
Original issue reported on code.google.com by [email protected]
on 1 Aug 2007 at 8:07
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 24 Jan 2008 at 5:08
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.