eepp
commented
6 years ago The difference for my application comes from the fact that my streams are truncated large files reserved on the system. So the stream can have padded zeroes.
You can't do that, sorry. All packets within a data stream file needs to fit perfectly, without a single byte of additional padding (that's not included in the packet size).
What you could do is, when the "close packet" callback is called, after successfully writing the packet to the file, add ctx->parent.packet_size (where ctx has type struct barectf_default_ctx *) to a counter initialized to 0, then truncate this file to this value divided by 8 when you're done tracing.
Or, in the resulting file, read byte at offset (n * packet size / 8), incrementing n until the byte is 0: it should be 0xc1 for any valid packet (if you have the packet header's initial magic member). Then, truncate the file to this offset.
Considering barectf only writes on close_packet calls, I assume no packet can be written partially.
No, packets should not be partial, unless your file writing method can fail.
prakashanurag
Context:
I have an application where the barectf output streams when parsed by babeltrace report the following errors and stops parsing the streams. Trace-compass loads more trace data from the same streams, but now I am concerned with lost events. The difference for my application comes from the fact that my streams are truncated large files reserved on the system. So the stream can have padded zeroes. Considering barectf only writes on close_packet calls, I assume no packet can be written partially.
W PLUGIN-CTF-NOTIF-ITER set_current_packet_content_sizes@notif-iter.c:<> Invalid packet size: packet context field indicates packet size is zero: notit-addr=<>, packet-context-field-addr=<> ...<snip> E CLI cmd_run@babeltrace.c:<> Graph failed to complete successfully