Project

General

Profile

Actions

Bug #1374

open

Babeltrace fails to read trace with no data stream type ID when the metadata superfluously specifies an ID

Added by Erica Bugden 12 months ago. Updated 12 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Start date:
04/26/2023
Due date:
% Done:

0%

Estimated time:

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:

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

traces.zip (3.49 KB) traces.zip Erica Bugden, 04/26/2023 02:04 PM
Actions #1

Updated by Erica Bugden 12 months ago

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.

Actions

Also available in: Atom PDF