From: ahmadkhorrami <ahmadkhorrami@ut.ac.ir>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Milian Wolff <milian.wolff@kdab.com>,
Steven Rostedt <rostedt@goodmis.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Linux-trace Users <linux-trace-users@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-trace-users-owner@vger.kernel.org,
Jin Yao <yao.jin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
Andi Kleen <ak@linux.intel.com>
Subject: Re: Wrong Perf Backtraces
Date: Tue, 31 Mar 2020 09:13:28 +0430 [thread overview]
Message-ID: <c1a64287c45da58def62a45e44525f02@ut.ac.ir> (raw)
In-Reply-To: <8cb4f94b11fbac6ca3a44b924b6ee7b3@ut.ac.ir>
Hi,
I checked the reported address in libgtk. GDB could map it to the source
files. Also, once, I read at Stackoverflow that perf gives up on
printing the backtrace (truncates the output backtrace), whenever it
detects a binary file without debug info. Could you describe more about
this situation?
And dear Mr. Olsa, if these cases do not occur on your system, could you
tell me how you installed the debug info for the binaries on your
system, please?
Regards.
On 2020-03-30 23:35, ahmadkhorrami wrote:
> Hi,
> Sorry, I did not pay attention to the fact that we need debug info to
> be able to decode the callchain. So, without complete debug info the
> backtrace (either the symbols or the addresses) is bogus. But you say
> that the backtrace portions containing binaries with full debug info
> are OK. Am I right? Please confirm if this is the case.
> If so, these portions may be enough for my current usecase.
> Regards.
>
> On 2020-03-30 18:19, ahmadkhorrami wrote:
>
> Hi,
> thanks, but I still do not understand the cause of the problem. It
> seems that it is purely a software bug and the callchain addresses seem
> wrong,by themselves. Am I right?
> Regards.
> On 2020-03-30 17:37, Jiri Olsa wrote:
>
> 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
next prev parent reply other threads:[~2020-03-31 4:43 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <157597d74ff17f781d9de7e7e3defd13@ut.ac.ir>
2020-03-22 20:24 ` Wrong Perf Backtraces ahmadkhorrami
2020-03-23 0:34 ` Steven Rostedt
[not found] ` <21b3df4080709f193d62b159887e2a83@ut.ac.ir>
2020-03-23 8:49 ` Jiri Olsa
2020-03-23 10:03 ` ahmadkhorrami
2020-03-25 15:18 ` ahmadkhorrami
2020-03-25 15:46 ` Jiri Olsa
2020-03-25 18:54 ` ahmadkhorrami
2020-03-25 18:58 ` Arnaldo Carvalho de Melo
2020-03-25 19:10 ` ahmadkhorrami
2020-03-25 19:28 ` Arnaldo Carvalho de Melo
2020-03-25 20:01 ` ahmadkhorrami
2020-03-25 20:39 ` Jiri Olsa
2020-03-25 21:02 ` Jiri Olsa
2020-03-25 21:09 ` Steven Rostedt
2020-03-25 21:37 ` ahmadkhorrami
2020-03-25 21:46 ` Jiri Olsa
2020-03-25 22:21 ` ahmadkhorrami
2020-03-25 23:09 ` ahmadkhorrami
2020-03-26 9:59 ` Jiri Olsa
2020-03-26 13:20 ` ahmadkhorrami
2020-03-26 15:39 ` Jiri Olsa
2020-03-26 18:19 ` ahmadkhorrami
2020-03-26 18:21 ` ahmadkhorrami
2020-03-27 9:20 ` Jiri Olsa
2020-03-27 10:59 ` ahmadkhorrami
2020-03-27 11:04 ` ahmadkhorrami
2020-03-27 12:10 ` Milian Wolff
2020-03-27 12:58 ` ahmadkhorrami
2020-03-27 13:25 ` Milian Wolff
2020-03-27 13:33 ` ahmadkhorrami
2020-03-27 18:43 ` ahmadkhorrami
2020-03-27 22:37 ` Jiri Olsa
2020-03-27 23:12 ` ahmadkhorrami
2020-03-28 23:34 ` Jiri Olsa
2020-03-29 0:43 ` ahmadkhorrami
2020-03-29 1:16 ` ahmadkhorrami
2020-03-29 11:19 ` Jiri Olsa
2020-03-29 11:52 ` ahmadkhorrami
2020-03-29 12:08 ` Jiri Olsa
2020-03-29 12:39 ` ahmadkhorrami
2020-03-29 13:50 ` Milian Wolff
2020-03-29 14:23 ` ahmadkhorrami
2020-03-29 19:20 ` Jiri Olsa
2020-03-30 6:09 ` Milian Wolff
2020-03-30 13:07 ` Jiri Olsa
2020-03-30 13:49 ` ahmadkhorrami
2020-03-30 19:05 ` ahmadkhorrami
2020-03-30 21:05 ` debuginfod-based dwarf downloading, was " Frank Ch. Eigler
2020-03-31 9:26 ` Jiri Olsa
2020-03-31 14:00 ` Frank Ch. Eigler
2020-03-31 4:43 ` ahmadkhorrami [this message]
2020-03-31 9:30 ` Jiri Olsa
2020-03-31 11:53 ` ahmadkhorrami
2020-03-31 12:43 ` ahmadkhorrami
2020-03-31 13:20 ` Jiri Olsa
2020-03-31 13:39 ` ahmadkhorrami
2020-03-31 14:44 ` Milian Wolff
2020-03-31 15:02 ` ahmadkhorrami
2020-03-31 15:05 ` ahmadkhorrami
2020-03-31 15:29 ` Milian Wolff
2020-03-31 16:10 ` Arnaldo Carvalho de Melo
2020-03-31 19:20 ` ahmadkhorrami
2020-03-31 19:17 ` ahmadkhorrami
2020-03-31 20:57 ` ahmadkhorrami
2020-04-04 1:01 ` ahmadkhorrami
2020-04-11 16:42 ` ahmadkhorrami
2020-04-11 21:04 ` ahmadkhorrami
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c1a64287c45da58def62a45e44525f02@ut.ac.ir \
--to=ahmadkhorrami@ut.ac.ir \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=jolsa@redhat.com \
--cc=linux-trace-users-owner@vger.kernel.org \
--cc=linux-trace-users@vger.kernel.org \
--cc=milian.wolff@kdab.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=yao.jin@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.