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 | milian.wolff@xxxxxxxx | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts
Attachment:
smime.p7s
Description: S/MIME cryptographic signature