Re: [PATCH v2 0/7] Final fixes before KS 2.0

From: Yordan Karadzhov <y.karadz@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-trace-devel@vger.kernel.org
Subject: Re: [PATCH v2 0/7] Final fixes before KS 2.0
Date: Tue, 18 May 2021 15:58:55 +0300	[thread overview]
Message-ID: <1bc8936b-6ec1-52bd-b292-52464d4ae315@gmail.com> (raw)
In-Reply-To: <20210518084607.7617ecab@gandalf.local.home>

On 18.05.21 г. 15:46, Steven Rostedt wrote:
>> Unfortunately I am not able to reproduce the crash. maybe it has
>> something to do with the particular data files you use.
> BTW, sometimes I need to do it twice. That is, I hit "Restore Last Session"
> twice.
> 

I restored the session 20 times in a row without having a crash.

> As this is a memory corruption issue, it will behave differently on
> different machines. Also, I do get the message:
> 
>    "Usage of trace_seq after it was destroyed"
> 
>>> Looks to be something is freed and then reused, because when I ran it under
>>> gdb, it crashed in allocation of memory (asprintf). That usually means that
>>> something was freed twice, someplace else. Or freed and then used.
>> Is it possible to send me a backtrace of the stack?
> Here's the backtrace from gdb:
> 
> (gdb) bt
> #0  0x00007ffff63cb02a in __strlen_sse2 () from /lib64/libc.so.6
> #1  0x00007ffff63994f8 in __vfprintf_internal () from /lib64/libc.so.6
> #2  0x00007ffff63aa015 in __vasprintf_internal () from /lib64/libc.so.6
> #3  0x00007ffff63844fa in asprintf () from /lib64/libc.so.6
> #4  0x00007ffff7ec88f9 in tepdata_get_latency (entry=<optimized out>,

This backtrace is very suspicious. It is exactly the same crash I had 
before applying [PATCH v2 6/7] kernel-shark: Fix the checking if 
"trace_seq" was destroyed.

I guess because of some reason it still fails to detect that the 
trace_seq was destroyed and needs to be initialized again.

Thanks!
Yordan