Closed jgalar closed 1 year ago
perhaps warn if the feature is disabled and the configuration contains more than one stream
Aren't stream IDs needed to function correctly if there is more than one stream? (Underlying question: Would it make more sense to fail than to warn in this case?)
Currently, the configuration parsing will fail if the it has more than one stream, but the data stream ids are undefined (i.e. when data-stream-type-id-field-type
is undefined).
config_parse_v3.py:641 Pseudo code:
if data_stream_id_field_type is None and data_stream_count > 1:
raise _ConfigurationParseError()
Actual code:
if dst_id_ft is None and dst_count > 1:
raise _ConfigurationParseError(f'`{dst_id_ft_prop_name}` property',
'Data stream type ID field type feature is required because trace type has more than one data stream type')
More context For example, the following barectf 2 config:
version: '2.2'
metadata:
type-aliases:
uint16:
class: int
size: 16
trace:
byte-order: little-endian
streams:
stream1:
$default: true
packet-context-type:
class: struct
fields:
packet_size: uint16
content_size: uint16
events:
my_event:
payload-type:
class: struct
fields:
my_field:
class: int
size: 8
stream2:
$default: true
packet-context-type:
class: struct
fields:
packet_size: uint16
content_size: uint16
events:
my_event:
payload-type:
class: struct
fields:
my_field:
class: int
size: 8
gives this error:
Configuration: Cannot create configuration from YAML file
Trace:
Trace type:
`$features` property:
`data-stream-type-id-field-type` property: Data stream type ID field type feature is required because trace type has more than one data stream type
Aren't stream IDs needed to function correctly if there is more than one stream? (Underlying question: Would it make more sense to fail than to warn in this case?)
As far as I know, they are. Indeed, it would make more sense to fail in that case.
Proposed fix.
The fix commit message has more details, but it looks like barectf is currently in a grey area in the CTF 1.8 spec and that this issue is a shared responsibility (between barectf and CTF readers). I haven't looked at the babeltrace code, so exactly why/where things go wrong in babeltrace is speculation, but the fix does allow babeltrace to read the trace.
I'm going to report an issue in babeltrace (even though it's not necessarily worth fixing) mainly to document it.
ebugden: Aren't stream IDs needed to function correctly if there is more than one stream? (Underlying question: Would it make more sense to fail than to warn in this case?)
jgalar: As far as I know, they are. Indeed, it would make more sense to fail in that case.
My updated understanding of the code is that configuration will fail if:
So it looks like this already covers what should happen.
The code below is for more context, if desired.
config_parse_v3.py:631
if features_node is not None:
magic_ft = self._feature_ft(features_node, 'magic-field-type', magic_ft)
uuid_ft = self._feature_ft(features_node, 'uuid-field-type', uuid_ft)
# The following line sets 'dst_id_ft' to None if it is configured false
dst_id_ft = self._feature_ft(features_node, dst_id_ft_prop_name, dst_id_ft)
dsts_prop_name = 'data-stream-types'
dst_count = len(self._trace_type_node[dsts_prop_name])
try:
# Raise a configuration error if data stream IDs aren't specified and there is more than one data stream
if dst_id_ft is None and dst_count > 1:
raise _ConfigurationParseError(f'`{dst_id_ft_prop_name}` property',
'Data stream type ID field type feature is required because trace type has more than one data stream type')
🌈 Fixed!
@eepp This issue can be closed :sunflower:
Overview
I noticed that barectf (
c4c4606
) produces invalid traces - or at least, traces that babeltrace 1 & 2 can't decode - when thedata-stream-type-id-field-type
is disabled (set tofalse
in the configuration file).Reproducer
My reproducer is based on the
barectf-tracepoint
example.3.x
formatdata-stream-type-id-field-type
feature by settingdata-stream-type-id-field-type
tofalse
(the resulting config file follows).Makefile
's default targetbarectf-tracepoint-barectf-linux-fs
ctf-linux-fs
trace using Babeltraceconfig.yaml
Error messages produced by Babeltrace 1 & 2
Reading the resulting trace with Babeltrace 2 produces the following error
Reading the resulting trace with Babeltrace 1.5 produces the following error
Cause
The stream and event classes declared by barectf in the
metadata
file reference thestream_id
both implicitly (id
) or explicitly (stream_id
) which appears unexpected by both babeltrace versions.I have to check the CTF v1.8 spec, but I would be surprised if it addressed this case explicitly. Nonetheless, I think the easiest fix here is to omit those IDs when the feature is disabled and perhaps warn if the feature is disabled and the configuration contains more than one stream.