In shared library instead of function names it gives an address of the function in case of CPUPROFILE

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Code to analyze need to have a shared library, that is loaded by your
executable at run time. 
2. Both of them(shared library and the binary that loads shared library)
are linked by using  -ltcmalloc -lprofiler

CPUPROFILE=/tmp/mybin.prof binary 

pprof   binary /tmp/mybin.prof

gv 

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

In the graph for shared library it should show the function names but it
gives an address of the function. If shows the name of the functions which
are not not dynamically linked and are not present in the executable itself. 

What version of the product are you using? On what operating system?

uname -a
FreeBSD  6.2-RELEASE-p11 FreeBSD 6.2-RELEASE-p11 #0: Wed Feb 13 02:31:35
UTC 2008    
root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Product version  1.5

Original issue reported on code.google.com by contactm...@gmail.com on 7 Apr 2010 at 5:15

[GoogleCodeExporter]

(pprof) top
Total: 5496 samples
     459   8.4%   8.4%      459   8.4% std::less::operator
     216   3.9%  12.3%      216   3.9% 0x00000008018e39b7
     171   3.1%  15.4%      171   3.1% 0x000000080191e07f
     136   2.5%  17.9%      136   2.5% 0x00000008018e39b3

Original comment by contactm...@gmail.com on 7 Apr 2010 at 8:39

[GoogleCodeExporter]

This almost always means the library is compiled without debugging information.
Try running 'nm' on the library -- do you get any symbols that way?  What about 
'nm -
D'?

Original comment by csilv...@gmail.com on 7 Apr 2010 at 6:29

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Library is compiled with -g flag. 
I am getting symbols by running nm on library. 

It gives address followed by the mangled names. 

00000000000adee0 T _Z18foundDiscontinuitytttt
00000000000ae2c0 T _Z7StrlcpyPcPKcm
00000000001c9d20 V _ZGVZNK12IntegerIndex7epsilonEvE3res
000000000007ddf0 W _ZN10BufferPool11commitAllocEv

Original comment by contactm...@gmail.com on 9 Apr 2010 at 4:33

[GoogleCodeExporter]

Can you attach the profile file that you're passing to pprof?  And, if you're 
willing, 
the binary as well.  If not, instead do this:
   run pprof --raw binary profile-file
   attach the output of that to this bug report

My guess is that the library that you're not getting the symbols from, is a 
different 
one than the library you're running nm on.  But it's just a guess; the profiles 
should 
help me figure it out.

Original comment by csilv...@gmail.com on 9 Apr 2010 at 4:41

[GoogleCodeExporter]

Output gives some junk values in the end. In the beginning it gives something 
like 

0x00000008018d37b4 0x00000008018d37b4
0x00000008018e2bb8 0x00000008018e2bb8
0x00000008018e36d3 0x00000008018e36d3
0x00000008018d3c74 0x00000008018d3c74
0x00000000005644b5 find_ud
0x0000000000568dec Mark
0x0000000801902dea 0x0000000801902dea
0x00000008018d1544 0x00000008018d1544
0x00000000004e67c1 IpFields::isV6() const
0x00000000004e667c SctpMapFields::init(IpExtFields&)
0x00000008018e2ba6 0x00000008018e2ba6
0x00000008018fa4fc 0x00000008018fa4fc
0x0000000000566042 opt_blk
0x0000000801916206 0x0000000801916206
0x0000000801916195 0x0000000801916195
0x00000000005be84f std::_Bit_iterator_base::_M_incr(long)
0x0000000801916195 0x0000000801916195
0x00000000005be84f std::_Bit_iterator_base::_M_incr(long)
0x000000080191e071 0x000000080191e071
0x00000008018e2c51 0x00000008018e2c51
0x000000080191e08a 0x000000080191e08a
0x00000008018e2c79 0x00000008018e2c79
0x000000080087ddd3 0x000000080087ddd3
0x000000080191611b 0x000000080191611b
0x000000080191607d 0x000000080191607d
0x00000008018d85b8 0x00000008018d85b8
0x00000000005639b4 find_edom
0x0000000000566336 fold_edge
0x000000080191c9c8 0x000000080191c9c8
0x0000000000563a4d find_edom
0x000000080191622e 0x000000080191622e
---
--- profile
^@^@^@^@^@^@^@^@^C^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^B^@^@^@^@^@^@^@^N^@^@^@^@^@^@^@~C~P~M^A^H^@^@^@å~I~M^A^H^@^@^@^PÏ~Q^A^H^@^@^@
^D§~P^A^H^@^@^@~@¦~O^A^H^@^@^@k^F~O^A^H^@^@^@q^NO^@^@^@^@^@ýZN^@^@^@^@^@îéM
^@^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/^B^
@^@^@^@^@^@^@^O^@^@^@^@^@^@^@$9V^@^@^@^@^@M:V^@^@^@^@^@ÌpV^@^@^@^@^@@qV^@^@^@^@
^@âwU^@^@^@^@^@/~O]^@^@^@^@^@r~H]^@^@^@^@^@òøN^@^@^@^@^@§UN^@^@^@^@^@îéM^@
^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/^A^@^
@^@^@^@^@^@^O^@^@^@^@^@^@^@ñ(~R^A^H^@^@^@~Ià~Q^A^H^@^@^@ܶ~P^A^H^@^@^@`µ~O^
A^H^@^@^@³a~Q^A^H^@^@^@¨)~P^A^H^@^@^@²÷~N^A^H^@^@^@q^NO^@^@^@^@^@ýZN^@^@^@^
@^@îéM^@^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=�
�tmp/^F^@^@^@^@^@^@^@^O^@^@^@^@^@^@^@~_¦N^@^@^@^@^@~Yà~Q^A^H^@^@^@ܶ~P^A^H^@
^@^@`µ~O^A^H^@^@^@Yb~Q^A^H^@^@^@¨)~P^A^H^@^@^@²÷~N^A^H^@^@^@q^NO^@^@^@^@^@ý
ZN^@^@^@^@^@îéM^@^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^
?^@^@KE=¯tmp/^A^@^@^@^@^@^@^@
^@^@^@^@^@^@^@°º~R^A^H^@^@^@Nù~N^A^H^@^@^@q^NO^@^@^@^@^@ýZN^@^@^@^@^@îéM^@
^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/^C^@^
@^@^@^@^@^@^N^@^@^@^@^@^@^@¹à~Q^A^H^@^@^@ܶ~P^A^H^@^@^@`µ~O^A^H^@^@^@aa~Q^A
^H^@^@^@¨)~P^A^H^@^@^@²÷~N^A^H^@^@^@q^NO^@^@^@^@^@ýZN^@^@^@^@^@îéM^@^@^@^@
^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/^A^@^@^@^@^
@^@^@^L^@^@^@^@^@^@^@
^SP^@^@^@^@^@^W^QP^@^@^@^@^@à^PP^@^@^@^@^@Ø~NO^@^@^@^@^@Ó^VO^@^@^@^@^@º]N^@^
@^@^@^@îéM^@^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@
KE=¯tmp/^A^@^@^@^@^@^@^@
^@^@^@^@^@^@^@~QÀ~R^A^H^@^@^@ºø~N^A^H^@^@^@q^NO^@^@^@^@^@ýZN^@^@^@^@^@îéM^
@^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/^A^@
^@^@^@^@^@^@^O^@^@^@^@^@^@^@ÖeV^@^@^@^@^@ímV^@^@^@^@^@ØpV^@^@^@^@^@@qV^@^@^@^
@^@âwU^@^@^@^@^@/~O]^@^@^@^@^@r~H]^@^@^@^@^@òøN^@^@^@^@^@§UN^@^@^@^@^@îéM^
@^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/^A^@
^@^@^@^@^@^@^N^@^@^@^@^@^@^@^L~V\^@^@^@^@^@Q~L\^@^@^@^@^@/^?\^@^@^@^@^@Nu\^@^@^@
^@^@½×[^@^@^@^@^@]~Q]^@^@^@^@^@ê^LO^@^@^@^@^@ýZN^@^@^@^@^@îéM^@^@^@^@^@~Rm
M^@^@^@^@^@ª[M^@^@^@^@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/^B^@^@^@^@^@^@^@
^M^@^@^@^@^@^@^@Ô¶~P^A^H^@^@^@`µ~O^A^H^@^@^@aa~Q^A^H^@^@^@¨)~P^A^H^@^@^@²÷
~N^A^H^@^@^@q^NO^@^@^@^@^@ýZN^@^@^@^@^@îéM^@^@^@^@^@~RmM^@^@^@^@^@ª[M^@^@^@^
@^@~MXM^@^@^@^@^@Âìÿÿÿ^?^@^@KE=¯tmp/

I have cross checked that the library I am getting symbols is the same one that 
I am
running on. 

Original comment by contactm...@gmail.com on 9 Apr 2010 at 11:09

[GoogleCodeExporter]

There's an 'attach a file' link under the comment box -- can you attach the 
profile 
file using that?

Based on what you attached, it seems like the profile file is entirely binary 
data; 
there's nothing at the end of it with lines like this:
  2b71ce75c000-2b71ce7da000 r-xp 00000000 00:00 986793      /usr/grte/v1/lib64/libm-
2.3.6.so

Is that right?  If so, there's your problem.  Now we just have to figure out 
why the 
profiler isn't successfully dumping the library-map info for you.  Do any 
errors get 
printed to stderr when you're running your program?

Original comment by csilv...@gmail.com on 9 Apr 2010 at 4:15

[GoogleCodeExporter]

I can't attach the profile file as I mentioned above profiler is able to give, 
or the
file is having mangalled names for the functions of the binary but the problem 
occurs
with that of shared library only. I just pasted some of the sample output. You 
can
guide me what exactly are you looking at I will find and tell you. 

Original comment by contactm...@gmail.com on 10 Apr 2010 at 12:01

[GoogleCodeExporter]

I'm sorry, why can't you attach the profile file?  I'm not understanding 
something.  
You cut-and-paste it in comment 5; I'm asking for the same thing, just using 
the 
'attach a file' link instead of cutting and pasting.

Original comment by csilv...@gmail.com on 12 Apr 2010 at 6:10

[GoogleCodeExporter]

Any more word on this?  Seeing the actual profile (using the 'attach a file' 
link) will be necessary to debug this further, I think.

Original comment by csilv...@gmail.com on 7 Jun 2010 at 11:10

[GoogleCodeExporter]

I can't attach the file but what I can do is write some sample test code to 
help you in re producing this issue. 

Original comment by contactm...@gmail.com on 8 Jun 2010 at 5:06

[GoogleCodeExporter]

If you can reproduce the problem in some other way, I'm happy to take a look at 
that as well.  I just need some actual data to look at.  Though I'm still 
confused why you were able to cut-and-paste the file contents in comment 5, but 
are unable to attach the profile contents now.

Original comment by csilv...@gmail.com on 8 Jun 2010 at 7:13

[GoogleCodeExporter]

Any more word on this?  Without concrete data or example code, I'm going to 
have to close this CannotReproduce.

Original comment by csilv...@gmail.com on 2 Aug 2010 at 4:43

[GoogleCodeExporter]

It's been over a year.  Closing.

Original comment by csilv...@gmail.com on 31 Aug 2011 at 11:36

• Changed state: CannotReproduce

[GoogleCodeExporter]

If the profiler is flushed but not stopped (with ProfilerStop), this issue 
happens.  It's 100% reproducible for me.

Maybe the first flush should write out the maps, just in case ProfilerStop 
never happens.

Original comment by aml...@gmail.com on 1 Jun 2012 at 11:05