Re: Wrong Perf Backtraces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
Thanks. If you suggest the potentially bogus locations of the source code, I will give a try.
Regards.

On 2020-03-28 03:07, Jiri Olsa wrote:

On Fri, Mar 27, 2020 at 11:13:27PM +0430, ahmadkhorrami wrote:

Hi,
I revised the code. Hopefully, it works. Could you check it with your own
outputs? It is valuable for me to know if your output contains wrong
backtraces or not. Here is the link:
https://gofile.io/?c=rz2kGc

will check, so far caught one.. might be same case:

evince 2168454 1549196.055094:      43831 cycles:u:
ffffffffaec012f0 [unknown] ([unknown])
7f0dd44776b6 __mmap64+0x26 (inlined)
7f0dd44776b6 __mmap64+0x26 (inlined)

will try to investigate next week

thanks,
jirka

Regards.

On 2020-03-27 15:34, ahmadkhorrami wrote:

I do the following:
If this line is in the perf script backtrace:
7f21ffe256db g_main_context_iteration+0x2b
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
I run the following command:
gdb -batch -ex 'file /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4'
-ex 'disass g_main_context_iteration'.

Regards.

On 2020-03-27 15:29, ahmadkhorrami wrote:

Hi,
Thanks! Could you tell me what should be changed in order to make
the code runnable on your system, if it is possible?
Regards.

On 2020-03-27 13:50, Jiri Olsa wrote:

On Thu, Mar 26, 2020 at 10:49:12PM +0430, ahmadkhorrami wrote:

Hi,
Here is the link for the python script:
https://gofile.io/?c=1ZSLwe
It is written in python-3 and takes the perf script output as input.
It looks for consecutive repeated backtrace lines and checks if the
function
in these lines calls itself at the offset in the line (i.e., checks if
recursion is possible). If not possible it reports an error. Could
you check
to see if any error is detected in your outputs, please?
I'm getting tons of following output:

/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30: No such file or
directory.
No symbol table is loaded.  Use the "file" command.
7ffff71b9bc1 gtk_css_node_invalidate_timestamp+0x31
(/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)

I assume it's because I have all the dso binaries stored
under .biuldid path, while you check the output name

jirka

Regards.
On 2020-03-26 20:09, Jiri Olsa wrote:

On Thu, Mar 26, 2020 at 05:50:27PM +0430, ahmadkhorrami wrote:

Hi,
First of all, many thanks for your time. Did you say that the first
file has
problems?

The first file (http://gofile.io/?c=qk6oXv) has repeated gmallocn()s
while
the second (https://gofile.io/?c=oGxgSM) also has problems with
unmatched
(not necessarily repeated) function calls. I am not sure if the
kernel for
the second one is 5.4.7 or the generic Ubuntu kernel. But the first
one is
certainly 5.4.7. Just to be clear, there were many instances of these
unmatched <caller, callees>.
I can se all the files, but I just can't see the issue yet
but it's probably because of issues with perf archive..

let's see if somebody else can chime in

I have a simple python script that checks for this situation. It
disassembles functions using GDB and checks the (directly called)
target of
each caller. I will put some comments in the script and upload it.
Could you
check to see if the python script detects any mismatches in your
backtraces?
It takes the perf script output file as input. I will upload the
script in
an hour.
ok

jirka



[Index of Archives]     [Linux USB Development]     [Linux USB Development]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux