Closed GoogleCodeExporter closed 9 years ago
After patching libc with
http://comments.gmane.org/gmane.comp.lib.glibc.alpha/17093 (what fixed issue
#396) and updating perftools to version 2.0 I have:
1. dynamically linked test programm works fine under heapcheck;
2. test program with statically linked tcmalloc crashes.
Reproduction:
$ echo -e "#include <boost/thread.hpp>\nint main() { return 0; }" > test.cpp
$ g++ test.cpp -Wl,-Bdynamic -ltcmalloc -lc -ldl -lrt -o test
$ env HEAPCHECK=normal ./test
WARNING: Perftools heap leak checker is active -- Performance may suffer
Thread finding failed with -1 errno=1
Could not find thread stacks. Will likely report false leak positives.
No leaks found for check "_main_" (but no 100% guarantee that there aren't
any): found 17 reachable heap objects of 456 bytes
$ g++ test.cpp -Wl,-Bstatic -ltcmalloc -Wl,-Bdynamic -lc -ldl -lrt -o test
$ env HEAPCHECK=normal ./test
WARNING: Perftools heap leak checker is active -- Performance may suffer
Check failed: !do_main_heap_check: should have done it
Aborted (core dumped)
Backtrace:
$ g++ -ggdb3 test.cpp -Wl,-Bstatic -ltcmalloc -Wl,-Bdynamic -lc -ldl -lrt -o
test
$ env HEAP_CHECK_RUN_UNDER_GDB=1 HEAPCHECK=normal gdb ./test
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
Reading symbols from /home/ktrushin/c++/test_tcmalloc/test...done.
(gdb) run
Starting program: /home/ktrushin/c++/test_tcmalloc/test
WARNING: Perftools heap leak checker is active -- Performance may suffer
Check failed: !do_main_heap_check: should have done it
Program received signal SIGABRT, Aborted.
0xb7fdd424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd424 in __kernel_vsyscall ()
#1 0xb7d3d1ef in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7d40835 in __GI_abort () at abort.c:91
#3 0x08062af4 in HeapLeakChecker_AfterDestructors() ()
#4 0xb7d41f61 in __run_exit_handlers (status=0, listp=0xb7eb03e4,
run_list_atexit=true) at exit.c:78
#5 0xb7d41fed in __GI_exit (status=0) at exit.c:100
#6 0xb7d284db in __libc_start_main (main=0x804be44 <main()>, argc=1,
ubp_av=0xbffff104,
init=0x806daa0 <__libc_csu_init>, fini=0x806db10 <__libc_csu_fini>, rtld_fini=0xb7fed270 <_dl_fini>,
stack_end=0xbffff0fc) at libc-start.c:258
#7 0x0804bdb1 in _start ()
(gdb)
Core file attached.
Any suggestions how to fix the problem?
Original comment by Konstant...@gmail.com
on 24 May 2012 at 2:40
Attachments:
Ok I think I see what is going on here. There were some changes in recent glibc
that caused the ordering of thing in at_exit to change. There is a fix on the
main trunk that addresses this. Download and build the code from the main trunk
and you should be good to go.
Original comment by chapp...@gmail.com
on 23 Dec 2012 at 3:10
Original issue reported on code.google.com by
Konstant...@gmail.com
on 16 May 2012 at 1:17