Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: minyard@acm.org (Corey Minyard)
Subject: [lttng-dev] Extract lttng trace from kernel coredump
Date: Tue, 18 Feb 2014 15:36:03 -0600	[thread overview]
Message-ID: <5303D243.7090606@acm.org> (raw)
In-Reply-To: <271092494.27125.1392757335976.JavaMail.zimbra@efficios.com>

On 02/18/2014 03:02 PM, Mathieu Desnoyers wrote:
> ----- Original Message -----
>> From: "Corey Minyard" <minyard@acm.org>
>> To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>
>> Cc: "David Goulet" <dgoulet at efficios.com>, lttng-dev at lists.lttng.org
>> Sent: Tuesday, February 18, 2014 2:29:23 PM
>> Subject: Re: [lttng-dev] Extract lttng trace from kernel coredump
>>
>> I have attached some gdb macros for dumping LTT buffers from a kernel
>> coredump.  I haven't done a lot of testing, though.
> Very cool! I'll have a look when things get less busy here. I hope my
> earlier reply helps clearing things out.

Yes, I'm going through that and the code I have to get things clean.

>> I do have one question.  I've been getting the metadata by taking a
>> snapshot right when the trace starts and saving that to stick into the
>> trace output from the coredump.  Is that the best way, or is there some
>> other way I can extract it?  There doesn't seem to be a metadata channel
>> running in snapshot mode.
> Actually, it's better if you grab the metadata near when you grab the
> coredump. Grabbing the metadata at the beginning of your tracing session
> will not have the info about other modules that might be coming and going
> while tracing is active (which might contain tracepoints).
>
> You could grab the metadata from the coredump actually, this would be the
> best approach. Looking at lttng modules 2.4 rc, you will want to look at
>
>  /lttng-events.h
>
> struct lttng_session {
>   ...
>   struct lttng_metadata_cache *metadata_cache;
>   ...
> };
>
> Which has the metadata string:
>
> struct lttng_metadata_cache {
>         char *data;                     /* Metadata cache */
>         unsigned int cache_alloc;       /* Metadata allocated size (bytes) */
>         unsigned int metadata_written;  /* Number of bytes written in metadata cache */
>         struct kref refcount;           /* Metadata cache usage */
>         struct list_head metadata_stream;       /* Metadata stream list */
> };
>
> You simply need to dump this metadata string into a "metadata" file, add a
> "/* CTF 1.8 */\n line at the beginning, and this will generate a "text only
> CTF metadata", which can be read by babeltrace.
>
> If you happen to core dump while the metadata cache is being resized, you might
> encounter a corrupted metadata. It should not happen frequently, but it's possible.
> We could eventually change lttng_metadata_printf() so it makes sure to always
> keep a readable metadata around (by e.g. using kcalloc rather than krealloc and
> dealing carefully with cache_alloc vs data fields updates).
>
> Thoughts ?

Perfect, that's easy.  I'll do that.

Thanks again.

-corey



  reply	other threads:[~2014-02-18 21:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <52D46B33.4010401@acm.org>
     [not found] ` <20140114184243.GC8177@thessa>
     [not found]   ` <52D5A08F.4020204@acm.org>
     [not found]     ` <1303248645.9400.1390063653581.JavaMail.zimbra@efficios.com>
     [not found]       ` <52DAC820.7000005@acm.org>
     [not found]         ` <353610105.9520.1390071650232.JavaMail.zimbra@efficios.com>
2014-02-13 19:31           ` Corey Minyard
2014-02-18 20:02             ` Mathieu Desnoyers
2014-02-19 18:52               ` Corey Minyard
2014-02-18 19:29           ` Corey Minyard
2014-02-18 21:02             ` Mathieu Desnoyers
2014-02-18 21:36               ` Corey Minyard [this message]
2014-02-18 21:42               ` Mathieu Desnoyers
2014-02-18 21:59                 ` Mathieu Desnoyers

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=5303D243.7090606@acm.org \
    --to=minyard@acm.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox