| 4595
|
|
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>
|
Simon Marchi |
13 days ago
|
 |
|
| 4594
|
|
lib: validate iterator message packets
Validate that messages coming out of iterators have sensible packet
values. This applies to event and packet end messages: their packet
must match the packet of the previous packet beginning message.
Add a hash table to hold per-stream state, inside the
bt_message_iterator structure. Since this state will only be used for
dev assertions, for the moment, only create it if BT_DEV_MODE is
defined.
Discard the per-stream state when the iterator seeks (after which the
iterator is expected to produce a new message sequence, starting from
scratch).
If the iterator uses auto-seek to implement "seek ns from origin", we
need to discard the per-stream state twice: once after seeking the
beginning, and once after consuming messages until the desired point.
When a wrong packet is detected, print an error logging message with
some details, before the failed assertion message:
Babeltrace 2 library postcondition not satisfied.
------------------------------------------------------------------------
Condition ID: `post:message-iterator-class-next-method:message-packet-is-expected`.
Function: bt_message_iterator_class_next_method().
------------------------------------------------------------------------
Error is:
Message's packet 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, received-packet-addr=0x607000004310, expected-packet-addr=(nil)
Aborting...
The particular structure of the code is explained by the following
patch, which adds verification that the message sequence is as expected.
Both assertions (packet is expected, and message sequence is as
expected) need to know about the current packet (this state is
maintained by message_packet_is_valid), so must be in the same "for all
messages" loop. Alternatively, they could both track the current packet
independently, but that would be redundant.
But this form also allows putting more info about the problematic
message in the abort notice, which I think is nice.
Change-Id: I176417d9ae7b04a9c16ff975e008e208b173e3d2
Signed-off-by: Simon Marchi <simon.marchi@efficios.com>
Reviewed-on: https://review.lttng.org/c/babeltrace/+/10448
Tested-by: jenkins <jenkins@lttng.org>
Reviewed-by: Philippe Proulx <eeppeliteloop@gmail.com>
|
Simon Marchi |
13 days ago
|
|
|
| 4593
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4592
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4591
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4590
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4589
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4588
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4587
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4586
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4585
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4584
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4583
|
|
|
Philippe Proulx |
15 days ago
|
|
|
| 4582
|
|
|
Simon Marchi |
26 days ago
|
|
|
| 4581
|
|
|
Simon Marchi |
26 days ago
|
|
|
| 4580
|
|
|
Simon Marchi |
26 days ago
|
|
|
| 4579
|
|
|
Simon Marchi |
26 days ago
|
|
|
| 4578
|
|
|
Simon Marchi |
28 days ago
|
|
|
| 4577
|
|
|
Simon Marchi |
1 month ago
|
|
|
| 4576
|
|
|
Simon Marchi |
1 month ago
|
|
|
collapse all