Fix: `test_packet_seq_num.in`: change expected disc. packets messages order

Issue
=====
The `test_packet_seq_num` test expects that Babeltrace reports 3, 2, and
1 discard packets in three different messages for CTF trace
`2_streams_lost_in_2`. Babeltrace 1 reports this, but Babeltrace 2
reports 2, 3, and 1.

I believe it's a bug in Babeltrace 1 because it also reports time ranges
which cover the packets which have an unexpected sequence number.

For example, Babeltrace 1:

    [warning] Tracer lost 3 trace packets between [06:15:09.000000090]
    and [06:15:09.000000110] in trace UUID
    eb5045f7b471488eb963221ddf423a7, at path:
    "../ctf-traces/packet_seq_num/2_streams_lost_in_2", within stream id
    0, at relative path: "test_stream_1". You should consider recording
    a new trace with larger buffers or with fewer events enabled.

Babeltrace 2:

    WARNING: Tracer discarded 3 packets between [06:15:09.000000090] and
    [06:15:09.000000091] in trace "2_streams_lost_in_2" (UUID:
    eb5045f7-b471-488e-b963-0221ddf423a7) within stream
    "/home/eepp/dev/babeltrace/tests/ctf-traces/packet_seq_num/2_streams_lost_in_2/test_stream_1"
    (stream class ID: 0, stream ID: 1).

The `test_packet_seq_num` test does not check the reported time ranges,
but this shows that the packet sequence number check might not be done
at the same time in Babeltrace 1 and Babeltrace 2. Because the test
trace contains two data streams with an intersection, and packets were
discarded in this intersection, the order of the warnings is not
guaranteed to be the same.

The time ranges reported by Babeltrace 2 are correct, however. In the
example above, it's okay to report that three packets were discarded
between 06:15:09.000000090 and 06:15:09.000000110, but it's even more
precise to report that they were discarded between 06:15:09.000000090
and 06:15:09.000000091. The time range of the packet with an unexpected
sequence number is 06:15:09.000000091 to 06:15:09.000000110.

Solution
========
Change the test so that it expects 2, 3, and 1 now.

Known drawbacks
===============
Some incompatibility with Babeltrace 1 regarding the order of the
warnings printed by `sink.text.pretty`. However, the locations and the
time ranges of the messages in Babeltrace 2's output are correct.

Most tools and scripts which rely on Babeltrace's text output only check
if there's something (anything) written to the standard error stream
anyway to detect a problem. LTTng analyses is one of those.

Signed-off-by: Philippe Proulx <eeppeliteloop@gmail.com>

diff --git a/tests/cli/test_packet_seq_num.in b/tests/cli/test_packet_seq_num.in
index 9210abf79d2aa9d3ec4845ff62d14993a7ccdbd1..38a6bf29acbfcd34adcaa2772860621361185c5e 100644 (file)
--- a/tests/cli/test_packet_seq_num.in
+++ b/tests/cli/test_packet_seq_num.in
@@ -67,4 +67,4 @@ diag "2 streams, packets lost in one of them"
 test_lost "${BT_CTF_TRACES}/packet_seq_num/2_streams_lost_in_1" "2"
 
 diag "2 streams, packets lost in both"
-test_lost "${BT_CTF_TRACES}/packet_seq_num/2_streams_lost_in_2" "3,2,1"
+test_lost "${BT_CTF_TRACES}/packet_seq_num/2_streams_lost_in_2" "2,3,1"