archive mirror
 help / color / mirror / Atom feed
From: Yordan Karadzhov <>
To: Steven Rostedt <>
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: <> (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/
> #1  0x00007ffff63994f8 in __vfprintf_internal () from /lib64/
> #2  0x00007ffff63aa015 in __vasprintf_internal () from /lib64/
> #3  0x00007ffff63844fa in asprintf () from /lib64/
> #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.


  reply	other threads:[~2021-05-18 12:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 14:21 Yordan Karadzhov (VMware)
2021-05-17 14:21 ` [PATCH v2 1/7] kernel-shark: Preserve markers when appending data Yordan Karadzhov (VMware)
2021-05-17 14:21 ` [PATCH v2 2/7] kernel-shark: Preserve open graphs " Yordan Karadzhov (VMware)
2021-05-17 14:21 ` [PATCH v2 3/7] kernel-shark: Clear before loading new session Yordan Karadzhov (VMware)
2021-05-17 14:21 ` [PATCH v2 4/7] kernel-shark: Better handling of plugins when appending data file Yordan Karadzhov (VMware)
2021-05-17 14:21 ` [PATCH v2 5/7] kernel-shark: Do draw the combo point of the mark Yordan Karadzhov (VMware)
2021-05-17 14:21 ` [PATCH v2 6/7] kernel-shark: Fix the checking if "trace_seq" was destroyed Yordan Karadzhov (VMware)
2021-05-17 14:21 ` [PATCH v2 7/7] kernel-shark: No slash at the end of KS_PLUGIN_INSTALL_PREFIX Yordan Karadzhov (VMware)
2021-05-17 23:21 ` [PATCH v2 0/7] Final fixes before KS 2.0 Steven Rostedt
2021-05-17 23:28   ` Steven Rostedt
2021-05-18  7:30   ` Yordan Karadzhov
2021-05-18 12:46     ` Steven Rostedt
2021-05-18 12:58       ` Yordan Karadzhov [this message]
2021-05-18 13:44         ` Steven Rostedt

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [PATCH v2 0/7] Final fixes before KS 2.0' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).