HEAPCHECK output includes only leak memory addresses

[GoogleCodeExporter]

Hi. I have strange output list when I check my app for leaks. 

1.Dynamically linking -ltmalloc ("last", there are other libraries)
2.HEAPCHECK=normal HEAP_CHECK_MAX_LEAKS=100 ./app

I see 20 of 78 leaks:
Have memory regions w/o callers: might report false leaks
Leak check _main_ detected leaks of 2602306 bytes in 24404 objects
The 20 largest leaks:
Leak of 1132920 bytes in 9441 objects allocated from:
        @ 0x2b2ce4bde979 
        @ 0x4026fd 
        @ 0x2b2ce0ee7232 
        @ 0x2b2ce0ee828b 
        @ 0x2b2ce0eeb283 
        @ 0x2b2ce4bfafc9 
        @ 0x2b2ce4bfabbb 
        @ 0x2b2ce26fca1d 
        @ 0x4022aa 
        @ 0x4024c4 
        @ 0x3024e1d994 
        @ 0x401bb9 
Leak of 1024080 bytes in 8534 objects allocated from:
        @ 0x2b2ce4bde979
...

I'm using google-perftools 1.4 on Red Hat Enterprise 5.1 x64.

Why do I see only memory adresses, only 20 of 78 leaks? What are I doing
wrong? Thank you.

With best wishes, Konstantin.

Original issue reported on code.google.com by K.Gertse...@gmail.com on 9 Dec 2009 at 2:33

[GoogleCodeExporter]

You're only getting 20 leak reports because that's baked in to perftools 1.4; 
the 
HEAP_CHECK_MAX_LEAKS flag is only supported on svn-root, not on the latest 
release.

As for why you're not getting stack traces, usually this is because the 
addresses in 
question -- they may be in another library, not in your main app -- were not 
compiled 
with -g, so we don't have the necessary symbol information.  Would that explain 
it 
here?

Original comment by csilv...@gmail.com on 10 Dec 2009 at 12:35

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Addresses, really, are in my libraries compiled with option-g (I tried -g3 
option
also) as my app. I suppose that there are no symbol information, but I don't
understand reason, option -g was set.

Thank you. 

Original comment by K.Gertse...@gmail.com on 11 Dec 2009 at 11:20

[GoogleCodeExporter]

It's hard to guess what might be going on.  Does 'nm' on your libraries show 
symbols?
 Or maybe it's a RHEL issue?

One thing you could try doing is running pprof manually on the file that the
leak-checker emits (I think it emits a heap profile for reporting leak checks). 
 See
if pprof can see the symbols.  Or, if you're ok sharing the executable and/or 
source
code -- or can find a small example that triggers the bug -- maybe attach it to 
this
bug report.

Original comment by csilv...@google.com on 11 Dec 2009 at 8:22

[GoogleCodeExporter]

Command 'nm' shows symbols on my libraries. Where can I find heap profile (do 
you
mean "HEAPCHECK=normal" option)?
I had run my application with administrator privilege and output list had 
classes'
and functions' names (but without line number). Tell me please:

1. How does privilege influence on output list?
2. Why is there no number lines?
3. How can I get more than 20 leak reports (numbers from 20 to 78)?

Thank you.

Original comment by K.Gertse...@gmail.com on 10 Jan 2010 at 10:12

[GoogleCodeExporter]

} Where can I find heap profile (do you mean "HEAPCHECK=normal" option)?

Yes.  When the heap profiler reports a leak, it should say something like, 'run 
pprof 
... to get more information'.  Have you tried doing that?

} 1. How does privilege influence on output list?

Do you mean, you ran as root?  It shouldn't affect leak checking, as far as I 
know.

} 2. Why is there no number lines?

Hard to say.  You will probably have to dig into this one a bit by yourself.  
You can 
try to follow through what pprof is doing, especially when it calls out to nm 
and 
addr2line.

Original comment by csilv...@gmail.com on 11 Jan 2010 at 7:08

[GoogleCodeExporter]

Sorry, I haven't tried 'run pprof ...'. I'll do.
Yes, when I run as root output list has classes' and functions' names without 
line
numbers/ If not list shows only addresses mentioned above (perftools was 
installed
under root privilege).

Original comment by K.Gertse...@gmail.com on 12 Jan 2010 at 7:49

[GoogleCodeExporter]

} Sorry, I haven't tried 'run pprof ...'. I'll do.

Any word on how this works?

} Yes, when I run as root output list has classes' and functions' names without 
line
} numbers/ If not list shows only addresses mentioned above (perftools was 
installed
} under root privilege).

How perftools was installed shouldn't matter, but it might matter for the files 
it 
needs to read.  My guess is that either addr2line is set up to only be runnable 
as 
root, or maybe your root account and user account have a different 
LD_LIBRARY_PATH 
set up, so they are seeing different versions of the libraries.  Or maybe some 
other 
difference between your root and user account (besides the fact one has root 
privileges...)

Original comment by csilv...@gmail.com on 10 Mar 2010 at 6:33

[GoogleCodeExporter]

Fortunately, it works fine (with line numbers). Indeed, it may be concerned with
LD_LIBRARY_PATH.

And now I have a new problem with google-perftools 1.5. There is *** Break ***
segmentation violation (not everytime but in same line number) when I run my 
program
compiled with -ltcmalloc. When program is compiled without -ltcmalloc it runs 
fine.
Can You help me to find a reason?

Original comment by K.Gertse...@gmail.com on 11 Mar 2010 at 12:25

[GoogleCodeExporter]

It sounds like it's working fine with pprof?  So I should close this bug?

} And now I have a new problem with google-perftools 1.5. There is *** Break ***
} segmentation violation (not everytime but in same line number) when I run my 
program
} compiled with -ltcmalloc. When program is compiled without -ltcmalloc it runs 
fine.

Every time we've seen this happen, it's been because of a memory bug in the 
code -- 
usually something like a double-free, or writing to freed memory.  Whether or 
not 
these kinds of bugs cause a crash on a given memory allocator, is pretty 
arbitrary.

One way to track this down is to try libtcmalloc_debug instead of libtcmalloc.  
You 
can also try something like valgrind.

If you do track this down to a problem in perftools, please open it as a new 
bug.

Original comment by csilv...@gmail.com on 11 Mar 2010 at 9:39

• Changed state: NotABug

[GoogleCodeExporter]

Yes, it's working fine with pprof (though output list has no line numbers and no
source code without root privilege). this bug may be closed, thank you very 
much.

Thank you for advice. I also believe there is a memory bug in the code. I was
suprised that the error wasn't raised with program compiled without -ltcmalloc. 
What
does it mean?

Original comment by K.Gertse...@gmail.com on 12 Mar 2010 at 8:48

[GoogleCodeExporter]

Hello, I ahve the same problem, however  in my case the *same* executable gives 
the symbols or not depending 
with which options is run. Is there a way to obtain the output at the end of 
the program running pprof post-
mortem? Thanks

Original comment by federico...@gmail.com on 19 Apr 2010 at 3:42

[GoogleCodeExporter]

"When the heap profiler reports a leak, it should say something like, 'run 
pprof 
... to get more information'." Is it the answer?

Original comment by K.Gertse...@gmail.com on 19 Apr 2010 at 7:03

[GoogleCodeExporter]

Hello and thanks for your answer. Running pprof I can obtain the graphical info 
or a list without tracebacks, but I 
cannot reproduce the original info that is contained in the output of the 
program, unless I am missing 
something. Moreover I would think this should really considered a bug, because 
it does not work as it is 
supposed to. In my case it is a very large code which if run in one way ends 
with the traceback, and if run in 
another, ends with no traceback. Best,

Original comment by federico...@gmail.com on 19 Apr 2010 at 3:51

[GoogleCodeExporter]

} cannot reproduce the original info that is contained in the output of the 
program,
} unless I am missing

The graph contains the same information as the original traceback in the code, 
just 
in a different form.  Every node of the graph is showing how much memory is 
being 
leaked at that callsite.  The arrows between nodes shows the call-graph.

I realized I never answered this original question:
}  I was suprised that the error wasn't raised with program compiled without
} -ltcmalloc. What does it mean?

It doesn't mean much.  When there's a memory error, the allocator may crash or 
not -- 
either immediately or sometime in the future -- depending on how the allocator 
code 
happens to be written.  Bugs that may causes crashes on one allocator may cause 
silent corruption -- or nothing at all -- on another.  There's really no way to 
predict.

Original comment by csilv...@gmail.com on 19 Apr 2010 at 6:18