Inaccurate stack unwinding about gperftools HOT 4 CLOSED

Sorry, I didn't mention, that this problem is on i386 arch.

I think there's a way to have pprof show the addresses associated with each 
arrow,
which may help clarify what's going on.

Typically, we see _init charged for stuff that ought to go to a function, when 
that
function is in a shared library and we're unable to read the address info for 
that
shared lib.  Is it possible that's what's going on here?

You don't say if this is for a heap-profiler or a cpu-profile, but in general, 
the
last two caveats from the cpu-profiling html docs seem potentially relevant 
here:
---
#  If the program linked in a library that was not compiled with enough symbolic
information, all samples associated with the library may be charged to the last
symbol found in the program before the library. This will artificially inflate 
the
count for that symbol.

# If you run the program on one machine, and profile it on another, and the 
shared
libraries are different on the two machines, the profiling output may be 
confusing:
samples that fall within shared libaries may be assigned to arbitrary 
procedures.
---

perftools 0.93 was just released.  While I don't expect anything will have 
changed
between 0.92 and 0.93 that would affect this bug, you might try running again 
with
the new perftools to see if the problem has magically gone away.

I'm closing this bug as "Can not reproduce."  If you see the problem again, 
please
feel free to reopen, especially if you can point to some code that will 
reproduce the
problem.