[lttng-dev] Extract lttng trace from kernel coredump

[Corey Minyard]

On 02/18/2014 02:02 PM, Mathieu Desnoyers wrote:
>> Starting from the consumed position, dump data from pages until you hit
>> subbufer->data_size, then move to the next subbuffer.  On the last
>> subbuffer, you have to fill in the header and dump up to the offset.
> Not quite exactly. It's better to do:
>
> for each subbuffer between consumed and offset (inclusive)
>   - if commit_seq is multiple of subbuffer size
>     dump subbuffer->data_size
>   - if commit_seq is not a multiple of subbuffer size,
>     dump commit_seq % subbuf size bytes of data, filling up the
>     header accordingly.
>
> Basically, all data that was "being written" (between commit_seq % subbuf size
> and write offset % subbuf size) cannot be read, because it likely contains
> holes and/or incomplete data.
>
>> I think I'm missing something, though, because the data size of the last
>> subbuffer doesn't match the offset location in that subbuffer.  It's a
>> pretty good distance away.
> Does my explanation above help clear things out ?

Yes, I've modified the code a bit to use the hot commit data if
necessary, and to dump the metadata from the metadata cache.  A new
version is attached.

I also modified to use the flushed value if present.  The probabilities
of that situation causing a problem are pretty low, but this will avoid
any issue.  It looks correct to me.

-corey

> Thanks,
>
> Mathieu
>
>> Thanks,
>>
>> -corey
>>
>>> A good way to understand its layout is to look at:
>>>
>>> lttng-modules (master)
>>> lib/ringbuffer/ring_buffer_backend.c
>>>
>>> lib_ring_buffer_backend_allocate()
>>>
>>> lib/ringbuffer/backend_types.h
>>>
>>> struct lib_ring_buffer_backend
>>> struct lib_ring_buffer_backend_subbuffer
>>> struct lib_ring_buffer_backend_pages
>>> struct lib_ring_buffer_backend_page
>>>
>>> In your case, you never care about the bufb->buf_rsb (read-side owned
>>> subbuffer),
>>> because you always ever just write into it. buf_rsb is only useful when
>>> taking
>>> snapshots.
>>>
>>> bufb->buf_wsb[] has the mapping from sub-buffers write-side index within
>>> the buffer to the associated index into bufb->array[], which allows getting
>>> the
>>> actual sub-buffers and memory pages associated to each buffer.
>>>
>>> You'll notice that the "id" field within struct
>>> lib_ring_buffer_backend_subbuffer
>>> is actually made of a mask of many fields. In order to understand how to
>>> use it,
>>> see
>>>
>>> lib/ringbuffer/backend_types.h
>>>
>>> where we provide helpers to get and set the various information elements
>>> contained within the "id" field. See subbuffer_id*() functions and comments
>>> surrounding them.
>>>
>>> So you'll need to use the structures presented above to make sense of the
>>> memory
>>> layout of a buffer, and reorganize it into a CTF file that can be read by
>>> Babeltrace or other CTF trace readers.
>>>
>>> The algorithm you want to end up doing (offline, on a vmcore) is pretty
>>> much
>>> the same as grabbing an online snapshot (iterate from the consumer position
>>> up to
>>> the producer position, see
>>> lib/ringbuffer/frontend.h:ib_ring_buffer_snapshot() ).
>>> You will need an extra trick to handle the sub-buffer that was being
>>> written to
>>> at the time of the crash, by using the
>>>
>>> lib/ringbuffer/frontend_types.h struct commit_counters_hot "seq" field
>>>
>>> which is designed to track the contiguously committed data within the
>>> currently
>>> written buffer. This can be used at any point in time (whenever a crash
>>> occurs) to
>>> populate the last sub-buffer's content size, packet size, see:
>>>
>>> lttng-ring-buffer-client.h: client_buffer_end()
>>>
>>> and find out how much of the last sub-buffer needs to be copied into the
>>> output
>>> CTF trace.
>>>
>>> Thanks,
>>>
>>> Mathieu
>>>
>>>> Thanks,
>>>>
>>>> -corey
>>>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ltt.py
Type: text/x-python
Size: 17137 bytes
Desc: not available
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20140219/379ed30a/attachment.py>