Heap checker output is missing stack traces on i686 machine

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile the attached file with `g++ -o bug_repro -g -ggdb bug_repro.cc -
ltcmalloc`
2. Run it with `HEAPCHECK=normal ./bug_repro`

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

The expected output is a memory leak report with associated stack traces of 
allocation sites.

The actual output is the following:

---
$ HEAPCHECK=normal ./bug_repro
WARNING: Perftools heap leak checker is active -- Performance may suffer
Leak check _main_ detected leaks of 4 bytes in 1 objects
The 1 largest leaks:
$

---

That is, the stack traces are missing.

Versions of relevant software:

perftools version: 1.3, shared libs
perftools configure options: ./configure --disable-dependency-tracking --
enable-shared --disable-static
libtcmalloc.so.0.0.0: ELF 32-bit LSB shared object, Intel 80386, version 1 
(SYSV), not stripped

Distro: Ubuntu Hardy (Google flavor)

uname -a: Linux izar 2.6.24-24-generic #1 SMP Fri Jul 24 22:46:06 UTC 2009 
i686 GNU/Linux

gcc --version: gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

ld --version: GNU ld (GNU Binutils for Ubuntu) 2.18.0.20080103

apt-cache show libc6 | grep Version: 2.7-10ubuntu3

Note that the machine is running a 32-bit kernel and a mixed 32/64 
userspace, but all the code here is compiled for i686, so the stack issues 
on 64-bit systems shouldn't be relevant.

I'm a Googler, so if you need extra information/IM/access to my laptop for 
repro, I'm 'danderson'.

Original issue reported on code.google.com by david.jc...@gmail.com on 7 Aug 2009 at 11:20

Attachments:

• bug_repro.cc

[GoogleCodeExporter]

Oh, forgot to mention: `make check` reports all 31 tests pass successfully.

Original comment by david.jc...@gmail.com on 7 Aug 2009 at 11:38

[GoogleCodeExporter]

Hmm, this works for me when I try it:
---
Leak check _main_ detected leaks of 8 bytes in 2 objects
The 2 largest leaks:
Leak of 4 bytes in 1 objects allocated from:
        @ 0x400676 leak_some_memory
        @ 0x400696 main
        @ 0x2ace5298b1c4 __libc_start_main
Leak of 4 bytes in 1 objects allocated from:
        @ 0x400680 leak_some_memory
        @ 0x400696 main
        @ 0x2ace5298b1c4 __libc_start_main
---

So not only is it missing stack traces in your run, it's missing one of the 
memory leaks.

Weird that the unittests all pass but this doesn't.

Try changing the code of an existing test -- something like 
heap_checker_unittest --
and replace it with your code.  When you run 'make check' this test should fail 
now,
but then you can try running 'env HEAPCHECK=normal ./heap-checker_unittest' and 
see
if you still see the same weird behavior.  This will help us determine if it's 
the
build environment or something else.

Original comment by csilv...@gmail.com on 9 Aug 2009 at 5:12

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

After implementing your suggestion and poking around a bit, I've identified the 
cause of the lack of stack traces. I am building and 
installing tcmalloc and friends to a local prefix (a 'vendor' directory for my 
project), and using rpath and related tricks to get the 
libraries loaded correctly by my code at runtime.

I neglected to export PPROF_PATH, so the heap-checker could only report that it 
found a discrepancy in alloc/free counts, since pprof wasn't 
findable. Running the repro with PPROF_PATH exported correctly outputs the full 
heap-checker report, along with full stack traces, and hints 
on pprof commands/environment variables that might help further.

Shouldn't pprof-less output at least report allocation sites without symbols, 
along with the suggestions below the stack trace on how to 
track the problem down? Testing on another machine suggests that it should at 
least print function addresses without pprof's help, but on 
this laptop, the program appears to exit immediately before doing that.

As for the single stack trace problem, even with PPROF_PATH correctly exported, 
only one allocation is reported for bug_repro.cc, the second 
'new int'. Strangely, replacing the main() of heap-checker_unittest.cc with a 
call to leak_some_memory() *does* correctly report two 
allocation sites, suggesting that this is something specific to bug_repro.cc or 
how it is compiled. I tried compiling with -O2 -g (the 
options used to build the test), but no change.

I am unable to reproduce this on another machine with more recent software 
(both leaks are reported), so this looks like an issue specific 
to the tools on my laptop.

So, it looks like we have two separate but possibly related issues that only 
manifest themselves on this combination of hardware and tools. 
What fun.

Original comment by david.jc...@gmail.com on 10 Aug 2009 at 3:56

[GoogleCodeExporter]

Hmm, looks like most of this is unreproducible then.  However, I did verify 
that when
PPROF_PATH is set wrong, the symbol-gatherer behaves pretty badly (I get a 
SIGPIPE).
 I think it should be straightforward to fix, and I'll look to get that into the next
release.

Original comment by csilv...@gmail.com on 10 Aug 2009 at 5:24

• Changed state: Started

[GoogleCodeExporter]

I've fixed the PPROF_PATH part, at least, in perftools 1.4 (just released).  I'm
closing this bug, but feel free to reopen it if you can track this down to a 
bug in
perftools.

Original comment by csilv...@gmail.com on 11 Sep 2009 at 6:59

• Changed state: Fixed