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

[åæéå / HIRAMATUïMASAMI]

Hi Namhyung,

>From: Namhyung Kim [mailto:namhyung@xxxxxxxxx] On Behalf Of Namhyung Kim
>
>Hi Masami,
>
>On Thu, Dec 03, 2015 at 07:13:15AM +0000, åæéå / HIRAMATUïMASAMI wrote:
>> From: Namhyung Kim [mailto:namhyung@xxxxxxxxxx]
>> >
>> >On Thu, Dec 03, 2015 at 12:15:12AM +0000, åæéå / HIRAMATUïMASAMI wrote:
>> >> >From: Namhyung Kim [mailto:namhyung@xxxxxxxxx] 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.

Agreed, my concerning case may rarely happens, so beforehand we'll be able
to handle it. (anyway, we also can use gdb for that case)

I'm OK this only for the sigsegv backtrace. But at least I don't want to use
the perf_thread for the refcnt debugger, because gdb is useless for this kind
of debugging. I'd like to make it robust. That is my point.

Thank you,