Fix: msg-iter.c: create packet message with correct function
authorPhilippe Proulx <eeppeliteloop@gmail.com>
Wed, 27 Mar 2019 22:11:56 +0000 (18:11 -0400)
committerPhilippe Proulx <eeppeliteloop@gmail.com>
Thu, 2 May 2019 04:09:19 +0000 (00:09 -0400)
commitf5e11b5dffe3aa7566ce6bf16b3330e6ee7e87ac
treecae2b49b2ad5fc204f19470e3e4d96718cc092d9
parent7cbf8ab4c5c6966acb5b9e5812ab2891f0fcd069
Fix: msg-iter.c: create packet message with correct function

Issue
=====
With CTF metadata having a stream class with:

* A packet context not having `timestamp_begin` or `timestamp_end`
  fields.

* An event header having a field mapped to a clock class.

The result is a Babeltrace trace IR stream class with a default clock
class.

However the decoding process fails because, without `timestamp_begin`
and `timestamp_end` packet context fields, the current packet's
beginning and end times are never set, thus we call
bt_message_packet_beginning_create() and bt_message_packet_end_create()
to create the messages. This is a precondition break because when a
stream class has a default clock class, all the packet beginning, packet
end, and event messages must have default clock snapshots.

Solution
========
In create_msg_packet_beginning(), if the current packet's beginning time
property is not set, use the last packet's end time or 0 if this is
not set either.

In create_msg_packet_end(), if the current packet's end time property is
not set, use the current clock value, and set it as the current packet's
end time property so that it becomes the last packet's end time property
in bt_msg_iter_switch_packet().

Known drawbacks
===============
With this fix, the first packet beginning message's clock snapshot's raw
value is 0. This is probably not ideal, as we cannot know if there was
any stream activity between 0 and the first event's time. The real fix
should probably be to use the first event's time, but this would require
more work as we would need to decode the first event's header before
calling create_msg_packet_beginning().

It's not a problem to compute the stream intersection, as no messages
are created during the execution of the `trace-info` query, so both
properties, as returned by bt_msg_iter_get_packet_properties(), are not
set. However there's a bug in the `trace-info` query as of this patch:
it does not check if the properties are set or not.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>
plugins/ctf/common/msg-iter/msg-iter.c
This page took 0.024016 seconds and 5 git commands to generate.