Bug #1374
openBabeltrace fails to read trace with no data stream type ID when the metadata superfluously specifies an ID
0%
Description
Babeltrace is not able to read a trace that does not contain data stream IDs (empty packet header) when the metadata specifies an ID for the stream. Trace Compass is also unable to read this trace. If the lines mentioning the stream ID are removed from the metadata, then babeltrace is able to read the trace.
Does this need to be fixed?¶
This was first reported as a barectf issue https://github.com/efficios/barectf/issues/28 , but after further consideration the issue appears to be in a grey area in the CTF 1.8 specification. Whether it is the CTF generator's (barectf) responsibility or the CTF reader's responsibility is up for debate.
The superfluous metadata information need not prevent the trace from being parsed. For example, yactfr https://github.com/eepp/yactfr is able to read the trace. However, considering that:
- At least two CTF readers (babeltrace and Trace Compass) cannot read the trace, and
- It is easy to fix in barectf (Proposed fix: https://review.lttng.org/c/barectf/+/9868 )
this is not a high priority issue in babeltrace.
Context¶
- Background and reproducer: barectf github issue https://github.com/efficios/barectf/issues/28
- Background and specification discussion: barectf fix https://review.lttng.org/c/barectf/+/9868
Files
Updated by Erica Bugden over 1 year ago
- File traces.zip traces.zip added
Add traces archive:
- good-trace: Can be read by babeltrace
- bad-trace: Can't be read by babeltrace
good-trace has the data stream ID lines removed from the metadata, but is otherwise identical to bad-trace. The data streams in both traces are the same.