std::malloc is in a separated node?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. write a simple program using std::map
2. insert lots of entries
3. compile without tcmalloc

What is the expected output? What do you see instead?
a whole call graph should be output, but the final report shows _int_malloc(), 
with a big percentage, in a separated node which is not in any calling tree or 
path.  Has anybody else faced the same issue? How can i find which of my 
functions call _int_malloc most frequently?

What version of the product are you using? On what operating system?
v1.8.2 on Linux 2.6.9_5-9-0-0 x86_64

Please provide any additional information below.

Original issue reported on code.google.com by shawn.x....@gmail.com on 7 Sep 2011 at 8:03

[GoogleCodeExporter]

Is it possible the data is correct, and most of the time is spent in malloc?

Original comment by csilv...@gmail.com on 7 Sep 2011 at 10:01

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

yes, result is add below.
After some test I find it is likely the unwind issue. previous test is based on 
system default unwind(./configure --enable-frame-pointers). 

When I changed into libunwind-0.99, _int_malloc node is in the calling graph. 
is there any possible that default unwind can not work well in the glibc?

Original comment by shawn.x....@gmail.com on 8 Sep 2011 at 1:50

Attachments:

• google-perf.png

[GoogleCodeExporter]

} is there any possible that default unwind can not work well in the glibc?

Definitely.  We have several open issues with libunwind.  It's not quite 100% 
yet, at least from perftools's point of view, unfortunately.

Does this resolve the bug -- can I close it?  I'm not exactly sure where we are 
now.

Original comment by csilv...@gmail.com on 8 Sep 2011 at 5:20

[GoogleCodeExporter]

Sure, it can be closed. btw, is there 100% work well solution for stack unwind? 
or should I expect it in future release?

Original comment by shawn.x....@gmail.com on 8 Sep 2011 at 2:04

[GoogleCodeExporter]

OK, closing.

} is there 100% work well solution for stack unwind?

The only thing that works 100% of the time is to compile with 
-fenable-frame-pointers.  That has other costs as well.  Improvements in 
libunwind are up to the libunwind team.

Original comment by csilv...@gmail.com on 8 Sep 2011 at 8:06

• Changed state: NotABug