On Mon, Mar 30, 2020 at 08:09:53AM +0200, Milian Wolff wrote: > 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? right, but it's beyond my DWARF expertise ;-) we'll need to wait till one of you guys could take a look on it thanks, jirka
|