Only get addresses instead of file/line or function output

[GoogleCodeExporter]

What steps will reproduce the problem?
1.run my particular program (Singularity Viewer) with tcmalloc preloaded
2.read any kind of pprof output --text or --gv, --lines, --functions.

--files not sure i tested.

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

Symbols within linked in libraries get resolved properly!
Symbols within the main executable do not! instead getting only bunch of 
adresses, i.e.:
     0.2   8.1%  78.1%      0.2   8.1% 00000000087e8a63

addr2line fed with this exact address outputs function and file:line properly 
as expected

Funnily can't repro the problem on a minimal test program on my system, so 
there might be something "evil" with the project itself.

There are no warnings or errors output by pprof.

What version of the product are you using? On what operating system?
Perftools 1.6 debian package from your googlecode site
Ubuntu Linux 10.10, 32-bit i686
Linux kernel 2.6.36-zen
GNU Bunutils 2.20.51-system.20100908
(same --version output from nm, addr2line, c++filt)

I tried looking at pprof source but found it thoroughly confusing -.-
Where should i poke at at making perhaps some warning output by pprof to 
highlight the possible source of a problem? Any any tiny tiny hints on what 
could be going wrong pleeeeeeaseeeee?
Where should i poke to provide a fallback which uses addr2line and assumes the 
symbol is from main executable if all else fails?

Woould you like any further information? My project is this:
https://github.com/siana/SingularityViewer
And it's hoarding memory badly, in many dozens of places a handful of bytes a 
pop (not my bugs, inherited them), and cannot be valground because of 
performance constraints. Using a good memory profiler to track all this down is 
crucial. Crash rate for all applications based on Linden Lab source is around 
20%, many of them due to malloc fiasco after a few hours of use on 32-bit 
systems. The application shouldn't need 64-bit address space in principle and 
should ideally need only around 512mb RAM for itself plus 512mb mapped opengl 
stuff, tops, even under heavy use.

Lastie thankies for an otherwise great project, for a really swift and tight 
malloc implementation and variety of analysis and output possibilities, though 
this particular problem with perftools has been causing me days and days of my 
"spare" time poking around and frustration -.-

Original issue reported on code.google.com by siana.gearz on 9 Dec 2010 at 3:46

[GoogleCodeExporter]

Yes, I'm afraid pprof is hard to understand. :-(  Every time I hack on it I 
need to take a few minutes to remind myself what functions do what.

In this case, you'll want to look at why the addr2line call is failing.  The 
routine to look at in pprof is MapToSymbols().  The loop you want is the one 
over <SYMBOLS>.  You'll want to look at the file (on disk) $main::tmpfile_sym, 
to see what addresses are being passed in to addr2line.  You can see if those 
match up with your expectations (they may not be the exact same as the 
addresses in the profile file due to offsets and the like).  THen you can look 
at $_ inside the <SYMBOLS> loop to see what addr2line is giving back.

It's definitely possible to fall back on nm if addr2line doesn't work, but nm 
doesn't correctly handle inlined functions, which addr2line does, so it's 
really a solution of last resort.  Better is to figure out why addr2line isn't 
working, if you can.

Original comment by csilv...@gmail.com on 9 Dec 2010 at 9:47

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Did you ever have a chance to look into this?  I'm starting to think about 
getting ready to begin preparing for a new perftools release, and I'm hoping to 
resolve as many open issues before then, as I can.

Original comment by csilv...@gmail.com on 10 Jan 2011 at 1:42

[GoogleCodeExporter]

No, sorry. I got memory hoarding down considerably "by chance" and haven't 
looked into fixing pprof. I'm kind of on tight schedule right now too, sorry 
-.- And i overlooked your initial answer -.- Also it would be the first time i 
see/touch Perl code ever, i'll have to give me a few hours of crash-course till 
i can do anything there at all. But i'll give it a shot upcoming weekend.

Original comment by siana.gearz on 11 Jan 2011 at 9:43

[GoogleCodeExporter]

It's been a while, so closing this CannotReproduce.  Feel free to reopen if 
you're still seeing the trouble and can figure out what's going wrong (and 
ideally how to fix it :-) )

Original comment by csilv...@gmail.com on 1 Sep 2011 at 1:57

• Changed state: CannotReproduce