Messages in this thread | | | Date | Fri, 4 Dec 2015 22:15:16 +0900 | From | Namhyung Kim <> | Subject | Re: [PATCH v3] perf tools: Introduce perf_thread for backtrace |
| |
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
| |