Re: Wrong Perf Backtraces

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