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
|