Closed GoogleCodeExporter closed 9 years ago
Original comment by `` on 18 Jan 2012 at 9:30
Hmm, this looks like the same problems you reported in issue 66. I'm going to
merge
this with that one. I haven't forgotten about it! But it is strange -- I
haven't
seen this in other x86_64 machines I've tested on. I'm not sure what the issue
might
be. Is there any chance you can run one of the tests under gdb? That might
give
some insight into what's going on.
Original comment by csilv...@gmail.com
on 30 Jan 2009 at 10:46
I tried running the failed heap-checker_unittest under gdb and it seems to
disable
itself automatically as it notices gdb is active.
I attached the log of three runs, i) HEAPCHECK= ./.libs/lt-heap-checker_unittest
succeeds, ii) HEAPCHECK=local ./.libs/lt-heap-checker_unittest fails, iii)
HEAPCHECK=local gdb ./.libs/lt-heap-checker_unittest succeeds but disabled the
heap
checker.
How can I run the unit test under gdb?
Thanks
Original comment by nowo...@gmail.com
on 31 Jan 2009 at 12:11
Attachments:
Thanks for looking into this! To run the heap-checker under GDB, set the
environment
variable HEAP_CHECK_RUN_UNDER_GDB=1. You may also want to set
PPROF_PATH=src/pprof
(or whatever), to make sure the heap-checker can call out to pprof.
Original comment by csilv...@gmail.com
on 1 Feb 2009 at 3:14
Thanks Craig, I managed to run the unit test under gdb.
Attached is the log file of running lt-heap-checker_unittest under gdb and the
only
error seems to be this one:
In main(): heap_check=local
Thread finding failed with -1 errno=1
Could not find thread stacks. Will likely report false leak positives.
Have memory regions w/o callers: might report false leaks
I do not know any internals of how the heap checker finds the stack, but the
most
recent libraries are used:
linux-vdso.so.1 => (0x00007fff705fe000)
libtcmalloc.so.0 => /tmp/google-perftools-1.0/.libs/libtcmalloc.so.0
(0x00007fe367fe1000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fe367cd4000)
libm.so.6 => /lib/libm.so.6 (0x00007fe367a4f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fe367837000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fe36761b000)
libc.so.6 => /lib/libc.so.6 (0x00007fe3672a9000)
libunwind.so.7 => /opt/libunwind-0.98.6/lib/libunwind.so.7 (0x00007fe36709c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe368244000)
where libunwind 0.98.6 has been compiled by myself.
Also, I tried to test tcmalloc separately by linking it against a program of
mine.
It immediately crashes upon start. (If this turns out to be a separate issue,
I can
file another ticket.)
Original comment by nowo...@gmail.com
on 1 Feb 2009 at 8:56
Attachments:
(See issue 66. It looks like the problem is with libunwind, not tcmalloc. You
can
get around it by configuring with --enable-frame-pointers. I've passed this on
the
libunwind people, who may try to fix this problem on their end for a future
release.)
Original comment by csilv...@gmail.com
on 2 Feb 2009 at 5:33
Original issue reported on code.google.com by
nowo...@gmail.com
on 30 Jan 2009 at 3:16Attachments: