Feature request: expose API to record stacktrace

[GoogleCodeExporter]

This is a feature request, not a bug report.

The google perftools code base already has ways to collect stacktraces and 
later draw nice graphs for them. For example, this is done while CPU 
profiling and heap profiling. Please expose a suitable API so that this 
functionality can be leveraged in other ways. That'll make the google 
perftools library extensible for functionality other than CPU and heap 
profiling.

As an example, I'd like to plot graphs that show the code paths where my 
mutexes undergo contention. If google perftools were to expose a suitable 
API, I can just insert those calls within my mutex implementation and 
thereby get a contention profile. 

Another example is to implement wallclock profiling using the above 
example. That is, I'd like to see where my threads are sitting irrespective 
of whether they are eating up CPU or not (this is very useful if threads 
are blocked on IO). Thus, I'd like to use setitimer() with ITIMER_REAL and 
then within the context of the signal handler, I'd like to call an API that 
google perftools exposes for recording the corresponding stacktrace. Later 
such stacktraces can be collated and plotted using 'pprof' by the perftools 
library.

Original issue reported on code.google.com by mohit.a...@gmail.com on 16 Nov 2009 at 2:34

[GoogleCodeExporter]

Please edit the subject to "Feature request: expose API to record stacktraces".

Original comment by mohit.a...@gmail.com on 16 Nov 2009 at 2:35

[GoogleCodeExporter]

Can you clarify a bit what API you had in mind?  perftools has no "way" of 
recording
stacktraces so that pprof can read them; if you look at
doc/cpuprofile-fileformat.html and a heap profile output file, you'll see the 
two
different formats we use for those two applications.  I'm not sure there can be 
a way
of just recording stacktraces; the traces themselves are meaningless without 
some
application-specific data associated with them.

Perhaps your best way forward would be to look at how we encode existing data, 
either
in the cpu profiler or the heap profiler, and try to write something equivalent 
for
an application you'd like (thread contention, perhaps).  That might serve as a 
good
way to start thinking about this problem, and what generalizations might make 
sense
for it.

Original comment by csilv...@gmail.com on 16 Nov 2009 at 4:04

• Changed title: Feature request: expose API to record stacktrace
• Added labels: Priority-Medium, Type-Enhancement

[GoogleCodeExporter]

I'm thinking that perftools can provide an API that takes in an object that has
methods for emitting extra data in a binary profile record and for reading it 
back.
Such an object might be subclassed from an abstract class that perftools can 
define.
This takes care of outputting and reading back the extra data that only the
application understands. Thus perftools will emit the stacktraces along with 
this
extra application specific data using this method.

The code that interprets these binary records and emits out graphs can 
similarly take
in user-defined functions or objects to do the needful.

Original comment by mohit.a...@gmail.com on 16 Nov 2009 at 6:00

[GoogleCodeExporter]

Ok, I think the best plan of attack is for you to propose a patch, and we can 
go from
there.  Ideally, the patch would include an actual user of this code so we can 
see
how it works in practice.

Original comment by csilv...@gmail.com on 16 Nov 2009 at 4:35

[GoogleCodeExporter]

Ok - I can work on that. But I may not be able to get to it soon.

Original comment by mohit.a...@gmail.com on 16 Nov 2009 at 4:51

[GoogleCodeExporter]

Any more word on this?

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

[GoogleCodeExporter]

> Any more word on this?

Sorry - no progress on this. It'll be really great if someone else can take 
this up - I myself am involved in a startup and probably won't have time for 
this at least this year.

Original comment by mohit.a...@gmail.com on 2 Aug 2010 at 4:56

[GoogleCodeExporter]

It's a year later, so I'm going to close this WillNotFix.  Feel free to reopen 
if you'd like to draw up a patch.

Original comment by csilv...@gmail.com on 31 Aug 2011 at 10:15

• Changed state: WontFix