casseopea2 / gperftools

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

x86_64 Ubuntu 8.10, libunwind 0.98.6, build succeeds but 3/23 unit tests fail #101

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. On x86_64 Ubuntu 8.10, I installed latest libunwind 0.98.6
2. CPPFLAGS=-I/opt/libunwind-0.98.6/include
LDFLAGS=-L/opt/libunwind-0.98.6/lib ./configure
--prefix=/opt/google-perftools-1.0 --enable-shared --enable-static
3. make && make check

What is the expected output? What do you see instead?

The compilation succeeds but 3 out of 23 tests fail.  I expect all tests to
pass.

The complete logfile is attached.

Original issue reported on code.google.com by nowo...@gmail.com on 30 Jan 2009 at 3:16

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by `` on 18 Jan 2012 at 9:30

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
(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