From mboxrd@z Thu Jan 1 00:00:00 1970 From: minyard@acm.org (Corey Minyard) Date: Wed, 19 Feb 2014 12:52:33 -0600 Subject: [lttng-dev] Extract lttng trace from kernel coredump In-Reply-To: <1494812851.27081.1392753777851.JavaMail.zimbra@efficios.com> References: <52D46B33.4010401@acm.org> <20140114184243.GC8177@thessa> <52D5A08F.4020204@acm.org> <1303248645.9400.1390063653581.JavaMail.zimbra@efficios.com> <52DAC820.7000005@acm.org> <353610105.9520.1390071650232.JavaMail.zimbra@efficios.com> <52FD1D81.60306@acm.org> <1494812851.27081.1392753777851.JavaMail.zimbra@efficios.com> Message-ID: <5304FD71.5040004@acm.org> 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: