Fix: Make traces with no data stream type ID readable by babeltrace
authorErica Bugden <ebugden@efficios.com>
Tue, 25 Apr 2023 16:01:36 +0000 (12:01 -0400)
committerErica Bugden <ebugden@efficios.com>
Fri, 28 Apr 2023 14:50:06 +0000 (10:50 -0400)
commitd024537859c1d869bfa1cedc8abe8e3f7a648faa
treeea49f8b9fc2ea3b671eeae40a25953eec83a44bb
parent3dca662da1619d2cb4e0f1eea3caf160b785d2df
Fix: Make traces with no data stream type ID readable by babeltrace

Currently, when the barectf configuration property
‘data-stream-type-id-field-type’ is false, barectf produces traces that
babeltrace (and Trace Compass) cannot parse.

To resolve this, remove all mentions of the data stream type ID from the
metadata file when there is no stream type ID field type feature.

Apparent cause:

When data stream type IDs are disabled, the barectf metadata file will
specify that the one data stream type has an ID of 0. This superfluous
information appears to be confusing to babeltrace even when the packet
header is explicitly empty (i.e. there is no mention of the stream type
ID in the actual trace data). This case falls into a grey area in the
CTF 1.8 specifcation (see below) and could arguably be a bug in
babeltrace since all the information needed to parse the trace
unambiguously is present in the metadata file. For example, the CTF
reader yactfr successfully reads such a trace. The stream type ID
information that barectf includes is superfluous, but not contradictory
of any data present in the trace.

However, add this fix because:
    a. Two common CTF trace format readers (babeltrace and
       Trace Compass) are unable to read these traces, and
    b. It is an easy fix in barectf.

CTF 1.8 specification:

This metadata issue is in a grey area of the CTF specification. The
specification says, “[The data stream type ID] field is optional if
there is only one [data stream type] in the metadata” and, “The [data
stream type ID] can be left out if there is only one [data stream type]
in the trace.” However, it does not say the data stream type ID _must_
be left out of the metadata if there is only one data stream type.

Implementation:

The condition added to the metadata Jinja template simply checks that
‘data-stream-type-id-field-type’ is not None. This works when
‘data-stream-type-id-field-type’ is set to false in the configuration,
because the data stream type ID field type will be set to None when the
trace type is created in config_parse_v3.py:

    dst_id_ft = self._feature_ft(...)

Testing:

The test does not check that babeltrace can read the trace, but it does
test that the lines mentioning the stream id are not present in the
generated metadata. Removing these lines has been manually verified to
be sufficient to allow babeltrace to read the trace.

The test source is adapted from the barectf test two-packets.c

Change-Id: I9de677440b98c41afe592d21a2ec18aa3c2e5bec
Signed-off-by: Erica Bugden <ebugden@efficios.com>
barectf/templates/metadata/metadata.j2
tests/tracing/configs/basic/ds/no-dst-id.yaml [new file with mode: 0644]
tests/tracing/expect/basic/ds/no-dst-id.data.expect [new file with mode: 0644]
tests/tracing/expect/basic/ds/no-dst-id.metadata.expect [new file with mode: 0644]
tests/tracing/src/basic/ds/no-dst-id.c [new file with mode: 0644]
This page took 0.025529 seconds and 4 git commands to generate.