search

blueszhangsh / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

env HEAPCHECK=normal ./myapp just doesn't work on Linux #153

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.
./configure --prefix /usr/pkg
make
make install
2.
~> cat main2.c
#include <malloc.h>

int main (int argc, char **argv)
{
        char * p = (char *) malloc (500000);

        return 0;
}
~> gcc -o main2 main2.c -L/usr/pkg/lib -Wl,-rpath -Wl,/usr/pkg/lib -l tcmalloc
~> ldd ./main2
        libtcmalloc.so.0 => /usr/pkg/lib/libtcmalloc.so.0 (0xb7eeb000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x4da7e000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x4de7d000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x4dbb7000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4de70000)
        /lib/ld-linux.so.2 (0x4da65000)
~> env HEAPCHECK=normal ./main2
WARNING: Perftools heap leak checker is active -- Performance may suffer
No leaks found for check "_main_" (but no 100% guarantee that there aren't
any): found 18 reachable heap objects of 500604 bytes
~>
~> uname -a
Linux chel 2.6.26.1 #1 SMP Mon Oct 6 18:40:10 EEST 2008 i686 GNU/Linux
~>

What is the expected output? What do you see instead?
It is not clear for why it says `No leaks found for check "_main_"'

What version of the product are you using? On what operating system?
1.3
Linux Debian etch
glic-2.3.6

Please provide any additional information below.

Original issue reported on code.google.com by a.cheu...@gmail.com on 13 Jul 2009 at 3:24

GoogleCodeExporter commented 9 years ago 
Hmm, when I try it, it correctly finds the leak.

This may be a tricky one to track down.  First step is to try all the unittests 
that
come with the package (via 'make check').  Do they all pass for you?

Original comment by csilv...@gmail.com on 14 Jul 2009 at 12:17

GoogleCodeExporter commented 9 years ago 
It's not clear for me where the test begins and where it ends but it says
...
Testing ./heap-checker_unittest with HEAPCHECK= ... FAILED
Output from the failed run:
----
HeapLeakChecker got turned off; we won't test much...
Check failed: pthread_create(&tid, &attr, HeapBusyThreadBody,
reinterpret_cast<void*>(i)) == 0

Adding pthread-specifics for thread 3015136960 pid 10111
Creating extra thread 1
A new HeapBusyThread 0
Adding pthread-specifics for thread 3014974384 pid 10111
Creating extra thread 2
A new HeapBusyThread 1
Adding pthread-specifics for thread 2810170288 pid 10111
Creating extra thread 3
A new HeapBusyThread 2
Adding pthread-specifics for thread 2605366192 pid 10111
Creating extra thread 4----
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:
---
Turning perftools heap leak checking off
HeapLeakChecker got turned off; we won't test much...
Check failed: pthread_create(&tid, &attr, HeapBusyThreadBody,
reinterpret_cast<void*>(i)) == 0

Adding pthread-specifics for thread 3015022272 pid 10152
Creating extra thread 1
A new HeapBusyThread 0
Adding pthread-specifics for thread 3014822832 pid 10152
Creating extra thread 2
A new HeapBusyThread 1
Adding pthread-specifics for thread 2810018736 pid 10152
Creating extra thread 3
A new HeapBusyThread 2
Adding pthread-specifics for thread 2605214640 pid 10152
Creating extra thread 4---
FAIL: heap-checker-death_unittest.sh
...
======================================
2 of 31 tests failed
Please report to opensource@google.com
======================================

Original comment by a.cheu...@gmail.com on 14 Jul 2009 at 8:19

GoogleCodeExporter commented 9 years ago 
This is weird:
---
Check failed: pthread_create(&tid, &attr, HeapBusyThreadBody,
reinterpret_cast<void*>(i)) == 0
---

Do you know why pthread_create might be failing?  If you can, try running the 
test in
gdb:
   env HEAPCHECK=normal HEAP_CHECK_RUN_UNDER_GDB=1 LD_LIBRARY_PATH=.libs
.libs/lt-heap-checker_unittest

You may need to put a breakpoint at the pthread_create line, and then after it 
fails,
you can print errno to see what might be going on.  Seems like something is 
wrong,
but I can't tell what it might be.

Original comment by csilv...@gmail.com on 14 Jul 2009 at 9:33

GoogleCodeExporter commented 9 years ago 
Any more news on this?

Original comment by csilv...@gmail.com on 14 Oct 2009 at 11:23

GoogleCodeExporter commented 9 years ago 
errno = 12

ulimits:
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) 650000
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) 800000
open files                      (-n) 5000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) 0
stack size              (kbytes, -s) 3000
cpu time               (seconds, -t) unlimited
max user processes              (-u) 400
virtual memory          (kbytes, -v) 800000
file locks                      (-x) unlimited

Original comment by a.cheu...@gmail.com on 15 Nov 2009 at 7:34

GoogleCodeExporter commented 9 years ago 
Forgot to say that 12 means "Cannot allocate memory"

Original comment by a.cheu...@gmail.com on 15 Nov 2009 at 7:36

GoogleCodeExporter commented 9 years ago 
A bit of google research shows this:

http://www.parkes.atnf.csiro.au/observing/documentation/computing_notes/linux_th
reads.html

It looks like that's the problem here -- you have 3M stack size (ulimit -s).  
See also
   http://sourceware.org/ml/glibc-bugs/2007-03/msg00086.html

What happens if you do 'ulimit -s unlimited' and try running the tests again?

Original comment by csilv...@gmail.com on 16 Nov 2009 at 3:49

GoogleCodeExporter commented 9 years ago 
With "ulimit -s unlimited" "make check" succeeds for 1.3 and 1.4.

Original comment by a.cheu...@gmail.com on 17 Nov 2009 at 7:03

GoogleCodeExporter commented 9 years ago 
OK, I'm going to close this as NotABug, then, since it doesn't seem to be a 
problem
in perftools.  I'm not sure if there's a good way to modify the test to make it 
more
reliable, but since there's such an easy workaround for the test, I think it's 
ok
just to close this.

Original comment by csilv...@gmail.com on 17 Nov 2009 at 7:13