Re: [PATCH v3] perf tools: Introduce perf_thread for backtrace

[Namhyung Kim <namhyung@kernel.org>]

Hi Masami,

On Thu, Dec 03, 2015 at 07:13:15AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote:
> From: Namhyung Kim [mailto:namhyung@kernel.org]
> >
> >On Thu, Dec 03, 2015 at 12:15:12AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote:
> >> >From: Namhyung Kim [mailto:namhyung@gmail.com] On Behalf Of Namhyung Kim
> >> >
> >> >Backtrace is a crucial info for debugging.  And upcoming refcnt
> >> >tracking facility also wants to use it.
> >>
> >> Note that the refcnt backtrace symbol resolution will work at
> >> exit. This means that it can not depend on the feature in perf
> >> tools itself. (and of course, since the refcnt tries to find unused
> >> objects in perf tools at exit, if we use perf_thread, it will
> >> detect the objects related to the perf_thread are leaked)
> >
> >Hmm.. right.
> >
> >I think we can leave the perf_thread outside of refcnt infrastructure.
> >IOW it should be created before refcnt debugging is activated and
> >released after refcnt is done.  What do you think?
> 
> Would you mean we don't debug the objects related to a perf_thread?
> It will mean that you don't debug anything, since perf_thread involves
> most of refcnt using objects, like dso, map, map_groups etc. And some
> bugs are actually found at where those objects are handled.
> 
> I would not like to care about the output quality of the backtrace_symbols.
> I only need the top 2-3 addresses of the backtrace buffer, because I have
> (eu-)addr2line command to find the actual source code lines from those
> addresses :). If you need, I can also provide an address decoder awk/shell
> script for that.
> 
> Instead, I prefer to avoid complexity on the "debugging feature"(because
> it can introduce new bugs,) and make it more robust (e.g. if we failed to
> get symbol, just shows the raw address)
> 
> BTW, the robustness is a key point for debugging. Please consider the case
> that you hit an error on the objects in the perf_thread, it could cause
> double fault(segv again) on the same object. That is what I actually don't
> want.

I understand your point.  If you object, I won't insist it strongly.

It's possible there's a bug in perf_thread symbol resolution.  But
it's pretty straightforward and simple use case so if there's a bug in
that code, it should be found beforehand IMHO.

Thanks,
Namhyung