[lttng-dev] Extract lttng trace from kernel coredump

[mathieu.desnoyers@efficios.com (Mathieu Desnoyers)]

----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> To: minyard at acm.org
> Cc: lttng-dev at lists.lttng.org
> Sent: Tuesday, February 18, 2014 4:02:15 PM
> Subject: Re: [lttng-dev] Extract lttng trace from kernel coredump
> 
> ----- 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.
> 
> > 
> > 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).

Oops, I meant "kzalloc".

I'm attaching a patch that should take care of making sure it is always in
a valid state when a core dump occurs. You should be able to safely read
"metadata_flushed" bytes of data at any time. Whatever has been flushed
should be parseable by Babeltrace.

Thoughts ?

Thanks,

Mathieu

> 
> Thoughts ?
> 
> Thanks,
> 
> Mathieu
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: metadata-core-dump.patch
Type: text/x-patch
Size: 6041 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20140218/45a87053/attachment-0001.bin>