lib: validate iterator message sequence
authorSimon Marchi <simon.marchi@efficios.com>
Fri, 10 Nov 2023 20:26:15 +0000 (20:26 +0000)
committerPhilippe Proulx <eeppeliteloop@gmail.com>
Wed, 22 Nov 2023 16:55:42 +0000 (11:55 -0500)
commit0121936a17b5964dd23e8dc291b1371d59de399f
tree466cc8876f3b7ad6016a75fe3ab8817cb563c7aa
parent9340eff9237ee05d044f7953495300506e152315
lib: validate iterator message sequence

Validate that the sequence of messages produced by iterators respects
the sequence defined by the Message Interchange Protocol (MIP) [1].

    Without packets
        SB (E | DE)* SE

    With packets
        SB ((PB (E | DE)* PE) | DE | DP)* SE

Validate that when an iterator returns
BT_MESSAGE_ITERATOR_CLASS_NEXT_METHOD_STATUS_END, all streams are
properly ended (we have received a stream end message for all streams).

Add an expected_msg_types field to the iterator's per_stream_state
structure, which holds a bit mask of the message types the iterator is
allowed to emit next.

Use the cur_packet field that is maintained by
message_packet_is_valid when processing a discarded events message.  We
need to know if we are in a packet or not to determine the following
valid message types (DE appears twice in the "With packets" sequence
above, once within a packet and once outside a packet).

It doesn't matter in which order the two assertions are placed, since
the "sequence is as expected" assertion doesn't use the cur_packet field
when handling the "packet beginning" and "packet end" messages.
However, I think that it is more useful to have the "sequence is as
expected" first.  Some mistakes, like the following sequence where a
packet beginning message is forgotten:

    ... PB E E PE E E PE ...

... would cause both assertions to fail.  But the "sequence is as
expected" assertion points closer to the root cause of the problem than
the "packet is expected" one, which points more to a symptom.  So, if
both assertions would fail, I prefer that we show the "sequence is
as expected" one.

Here's an example of the error message that is printed when an error is
detected.  In this case, a packet beginning message was forgotten.

    Babeltrace 2 library postcondition not satisfied.
    ------------------------------------------------------------------------
    Condition ID: `post:message-iterator-class-next-method:mip-message-sequence-is-expected`.
    Function: bt_message_iterator_class_next_method().
    ------------------------------------------------------------------------
    Error is:
    MIP message sequence is not expected: stream-addr=0x60d000001d80, stream-id=0, iterator-addr=0x611000004c80, iterator-upstream-comp-name="source.gpx.GpxSource", iterator-upstream-comp-log-level=WARNING, iterator-upstream-comp-class-type=SOURCE, iterator-upstream-comp-class-name="GpxSource", iterator-upstream-comp-class-partial-descr="", message-addr=0x607000004540, message-type=EVENT, expected-msg-types=STREAM_END|PACKET_BEGINNING
    Aborting...

[1] https://babeltrace.org/docs/v2.0/libbabeltrace2/group__api-msg.html#api-msg-seq

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