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)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Fri, 3 May 2019 22:19:39 +0000 (18:19 -0400)
commit92f86a9e7a3cf684ea60cd378a364f63751e3e4b
treecf852dffaf88067f34e96833ddb57359538e9215
parent28faa4165d59a9f1180cbc8589fdebcc0fc14746
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.02574 seconds and 4 git commands to generate.