Re: Wrong Perf Backtraces

On Sonntag, 29. März 2020 21:20:10 CEST Jiri Olsa wrote:
> On Sun, Mar 29, 2020 at 03:50:57PM +0200, Milian Wolff wrote:
> > On Sonntag, 29. März 2020 14:39:33 CEST ahmadkhorrami wrote:
> > > Thanks. I did both of your changes. Perhaps some outputs are revised.
> > > But I still have repeated function calls and the script detects them.
> > 
> > > Here is one of them when the sampling period is 1000 events:
> > <snip>
> > 
> > > Here, we have two consecutive "7f91788120b5
> > > gtk_widget_propagate_state+0x195
> > > (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30) gtkwidget.c:0" lines,
> > > while "gtk_widget_propagate_state+0x195" is not recursive. It should
> > > call "gtk_container_forall", which does not occur even after the second
> > > (inner) call.
> > 
> > Potentially you are just lacking some debug symbols here for this GTK
> > library. note that "gtkwidget.c:0" is bogus already - the line numbers
> > start with 1, so
> could we just skip those then? pass on all zero lined inlines
> and not add/display them

I guess so - but quite frankly I'm a bit uneasy to do this without further 
exploration about the actual causes here. Afaik DWARF does not say anything 
about the validity, so in theory there might be some language/compiler that 
encodes valid DWARF locations with line 0?

Generally, it would be quite interesting to figure out why there is /some/ 
DWARF data here such that the code thinks it's able to decode the inline frame 
but then fails and leads to this confusing result?

Cheers
-- 
Milian Wolff | [email protected] | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts