lib: validate monotonicity of messages from upstream component
authorSimon Marchi <simon.marchi@efficios.com>
Mon, 17 Jun 2019 23:18:13 +0000 (19:18 -0400)
committerJérémie Galarneau <jeremie.galarneau@efficios.com>
Thu, 18 Jul 2019 15:53:33 +0000 (11:53 -0400)
commite253ad8defdea7c050a4d4aea1504fb363c18fd8
tree9fb4a9384cd6cbf3cd16016411fa6e1a79bd32c2
parent4e85313577e3a610034d66787bc7dc45e91f38d7
lib: validate monotonicity of messages from upstream component

This patch adds two checks after having called an iterator's next
method, to verify the validity of what is returned.

Clock class compatibility
-------------------------

Check that the clock classes of new streams created through this
iterator are compatible with the clock classes of streams previously
created through the same iterator.

The first time a stream is created through an iterator, we save some
properties of that clock class (whether its origin is the Unix epoch,
and if it isn't, its uuid).  When new streams appear, we compare those
properties to make sure the clock classes of the new streams are
compatible with those properties.

Clock snapshots increase
------------------------

Check that the clock snapshots of all messages (that have one) don't go
back in time.

For each incoming message, if it has a clock snapshot, we compare it
with the clock snapshot of the previous message and assert that it isn't
lower (the "previous message time" is initialized to INT64_MIN).

Some messages don't have a clock snapshot, for those we do nothing.

I am not considering the "infinity" value that stream activity end
messages can have.  It would add a bit more complexity to validate them
propertly, because it's possible to have something like this:

    Stream 1: ...  EV(1)       SAE(inf)  SE
    Stream 2: ...        EV(2)               EV(10) ...

As you can see, it is possible to have a finite value (10) on stream 2
after having received an SAE message at infinity on stream 1.  We could,
validate that nothing with a finite clock snapshot comes on stream 1
specifically.  It would however require some per-stream data, which adds
a bit of complexity.  And since we plan on removing these messages
anyway, it doesn't seem to be worth the effort.

Change-Id: If18f475ed056fda77a539d700e6ad310111f6d6b
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/1486
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
src/lib/graph/iterator.c
src/lib/graph/message/iterator.h
This page took 0.025593 seconds and 4 git commands to generate.