search

aoyoo / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

print stacktrace internally (not using pprof) #293

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi,

I think that it will be much more convenient if tcmalloc would print backtraces 
in human readable format, rather than encrypted pprof format.

It will allow to run tcmalloc debug/heap profiler on an automated machine, and 
tell if there is a problem just by looking at the log.

attached a patch with the implementation of the backtrace, with using it yet 
(using will be submitted in another patch)

Yoni.

Original issue reported on code.google.com by jontra@gmail.com on 8 Dec 2010 at 1:14

Attachments:

GoogleCodeExporter commented 9 years ago 
} attached a patch with the implementation of the backtrace, with using it yet
} (using will be submitted in another patch)

Any chance you can make it part of this patch?  That would help a lot.  I'm 
confused how you intend to use this.  Is the idea to have the heap profile file 
have a human-readable stack trace, or something like that?

I'm not sure I understand the use-case you describe, or why it needs this 
functionality.  I guess you're running some application on a remote machine, 
that's linked with tcmalloc.  And it's running with heap-profiling turned on, 
so it's generating heap-profile output files?  But then you say you want to 
analyze problems by "looking at the log."  What log are you talking about?  How 
are these backtraces getting to that log?

Whatever technique you're using, why don't you just replace that with something 
like system("pprof <myprogram> <myprofile>")?  This will also allow for a lot 
more sophisticated analysis than just a stracktrace.

I guess I'm still trying to figure out what problem this patch is addressing.

Original comment by csilv...@gmail.com on 9 Dec 2010 at 4:47

GoogleCodeExporter commented 9 years ago 
No word on this bug in almost a year, so I'm closing it.  I still don't 
understand what problem it's trying to address.  The code looks like it's 
probably useful, but I can't accept it until I know how it might fit into the 
rest of perftools.  Anyone reading this, feel free to reopen if you can shed 
light on that issue and (ideally) can rework this patch into a standalone, 
functional piece of code.

Original comment by csilv...@gmail.com on 18 Oct 2011 at 4:53