profile is wrong (truncated?) when linked with libtcmalloc.so using -R flag

[GoogleCodeExporter]

What steps will reproduce the problem?
1. link any program with tcmalloc.so with -R <lib-path> -L <lib-path>
-ltcmalloc
2. run it: HEAPCHECK=normal HEAPPROFILE=my-profile <program>
3. pprof --gv <program> <profile> outputs: No nodes to print

What version of the product are you using? On what operating system?
0.98 on FreeBSD 7.1-PRERELEASE

Seems like -R flag (fixing library location) matters.

Original issue reported on code.google.com by visa_des...@yahoo.com on 6 Jan 2009 at 12:34

[GoogleCodeExporter]

Can you give a specific example of the command-line that you are using, with -R?

Does pprof give any other output except 'no nodes to print'?

One possibility is that pprof's calls to 'nm' etc are failing because nm 
doesn't know
what directories to look for for the shared libraries.  What happens if you do
   LD_LIBRARY_PATH=<lib-path>:<lib-path> LD_RUN_PATH=<lib-path>:<lib-path> pprof --gv ...
?

Original comment by csilv...@gmail.com on 6 Jan 2009 at 6:47

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 6 Jan 2009 at 6:47

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

command line example:
g++ -o test test.C -R /home/xxx/google-perftools-0.98/.libs -L
/home/xxx/google-perftools-0.98/.libs -ltcmalloc

One of the resulting profiles looks like this:
--- begin profile ---
heap profile:      9: 734007300 [    15: 734023686] @
     9: 734007300 [    15: 734023686] @

MAPPED_LIBRARIES:
<skipped mappings that look ok>
--- end profile ---

First section looks wrong to me: doesn't list enough entries and nothing after @
sign. Normal profile has ~10 lines there and addresses after @. pprof only 
outputs
'No nodes to print' and nothing else.

Also could you please reopen PR#89, it seems to be a legitimate problem, I added
details there. Thanks.

Original comment by visa_des...@yahoo.com on 6 Jan 2009 at 7:31

[GoogleCodeExporter]

I can't reproduce this.

Here's the system I tried it on:
$ uname -a
FreeBSD nimbus-016.corp.google.com 6.2-RELEASE-p5 FreeBSD 6.2-RELEASE-p5 #0: 
Thu May
31 11:17:39 PDT 2007

Here's what I ran:
tmp$ cat > test.cc
#include <stdlib.h>

int doit() {
   for (int i = 0; i < 1000; i++) {
     malloc(i);
   }
}

main() {
   doit();
   return 0;
}

$ g++ -o test test.cc -R /var/tmp/google-perftools-1.0/.libs -L 
/var/tmp/google-perftools-1.0/.libs -U __tcmalloc -ltcmalloc

(For some reason, I had to use the -U trick to get the linker to link in 
libtcmalloc
at all.)

$ env HEAPPROFILE=/var/tmp/foo ./test

$ cat /var/tmp/foo.0001.heap
heap profile:   1000:   499500 [  1002:   499535] @
  1000:   499500 [  1000:   499500] @ 0x080485d9 0x08048609 0x08048502 0x0000000
1
     0:        0 [     1:       17] @ 0x28126356 0x28128566 0x28128663 0x28099a5
6 0x280a0dbd 0x280866dd 0x28050983 0x2804db0e
     0:        0 [     1:       18] @ 0x28126356 0x28128566 0x28128663 0x28099a1
0 0x280a0dbd 0x280866dd 0x28050983 0x2804db0e

MAPPED_LIBRARIES:
---

When I run with pprof, everything works as expected.

I'm not sure what's going on in your case -- maybe running ldd on your test 
program
will make it a bit clearer?  Or using the debugger?

I'm not sure why you need -R in any case.  I don't know freebsd very well, but I
assume -R is the same as --rpath?  Is that necessary for correct execution in 
your
situation?

Original comment by csilv...@gmail.com on 7 Jan 2009 at 11:31

[GoogleCodeExporter]

It may be 7.1-related, you tried on 6.2-RELEASE which is quite old.

Virtually all regular FreeBSD users now run on 7.1. 6.2 is used mostly by those 
who
are waiting for the RELEASE label.

-R is used to force program to use a specific library vs. a default one. I used 
it to
stick to a particular libtcmalloc.so and discovered this problem.

I will do some debugging myself and see what's wrong.
Will post results here.

This isn't a major problem anyway.

Original comment by visa_des...@yahoo.com on 7 Jan 2009 at 11:47

[GoogleCodeExporter]

} I will do some debugging myself and see what's wrong.
} Will post results here.

Any more news on this?

} This isn't a major problem anyway.

I'll lower the priority, then. :-)

Original comment by csilv...@gmail.com on 6 Mar 2009 at 8:16

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

} I will do some debugging myself and see what's wrong.

Any updates on this?

Original comment by csilv...@gmail.com on 17 Mar 2010 at 11:16

[GoogleCodeExporter]

It's been over a year now, I'm closing this cannotreproduce.

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

• Changed state: CannotReproduce