heapcheck doesn't work with boost threads

[GoogleCodeExporter]

Given trivial program, heapcheck becomes stuck if boost thread is included in 
the program.

What steps will reproduce the problem?
1. echo -e "int main() { return 0; }" > test.cpp
2. g++ test.cpp -Wl,-Bstatic -ltcmalloc -Wl,-Bdynamic -lc -ldl -lrt -o test
3. env HEAPCHECK=normal ./test  # program returns immediately as expected

4. echo -e "#include <boost/thread.hpp>\nint main() { return 0; }" > test.cpp
5. g++ test.cpp -Wl,-Bstatic -ltcmalloc -Wl,-Bdynamic -lc -ldl -lrt -o test
6. env HEAPCHECK=normal ./test  # program gets stuck

What is the expected output? What do you see instead?
Expected: Immediately return
Observed on perftools 1.7: 
Hooked allocator frame not found, returning empty trace
Hooked allocator frame not found, returning empty trace
# And then program gets stuck.
Observed on perftools 2.0:
# No output
# Program gets stuck.

What version of the product are you using? On what operating system?
perftools versions evaluated: 1.7 from Ubuntu repository, 2.0 deb package from 
perftools site.  Ubuntu 12.04 32bits

Please provide any additional information below.
boost version 1.46. 

GDB backtrace using perftools 1.7:

env HEAP_CHECK_RUN_UNDER_GDB=1 HEAPCHECK=normal gdb ./test

GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu1) 7.4-2012.04
(gdb) run
Starting program: test 
Hooked allocator frame not found, returning empty trace
Hooked allocator frame not found, returning empty trace
^C #  I've interrupted program here by pressing Ctrl-C
Program received signal SIGINT, Interrupt.
0x08057154 in base::internal::SpinLockDelay(int volatile*, int, int) ()
(gdb) bt
#0  0x08057154 in base::internal::SpinLockDelay(int volatile*, int, int) ()
#1  0xbfffd51c in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Original issue reported on code.google.com by Konstant...@gmail.com on 16 May 2012 at 1:17

• Merged into: #437

[GoogleCodeExporter]

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:

• core

[GoogleCodeExporter]

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

• Changed state: Duplicate