From felix.moessbauer at siemens.com  Tue Aug  4 11:27:43 2026
From: felix.moessbauer at siemens.com (MOESSBAUER, Felix)
Date: Tue, 4 Aug 2026 15:27:43 +0000
Subject: babeltrace 2.1.2: sink.ctf.fs does not deduplicate identical clocks
Message-ID: <d0e142586819e25725452b2849308829c38216fb.camel@siemens.com>

Hi,

while porting the bt2-ftrace-to-ctf [1] plugin to babeltrace 2.1, I
noticed that the sink.ctf.fs creates invalid clock definitions if
multiple stream-classes share the same clock-class. In this case, the
clock definition is added multiple times to the CTF 2 metadata,
resulting in the following assertion on read-back:

ERROR:    [Babeltrace CLI] (babeltrace2.c:2705)
  Command-line error: retcode=1
CAUSED BY [Source auto-discovery] (autodisc/autodisc.c:493)
  babeltrace.support-info query failed.
CAUSED BY [libbabeltrace2] (lib/graph/query-executor.c:233)
  Component class's "query" method failed: query-exec-
addr=0x55cba00c12e0, cc-addr=0x55cba00b4100, cc-type=SOURCE, cc-
name="fs", cc-partial-descr="Read CTF traces from
  the file sy", cc-is-frozen=0, cc-so-handle-addr=0x55cba00b1930, cc-
so-handle-path="<...>/build/babeltrace-plugin-ctf.so",
  object="babeltrace.support-info", params-addr=0x55cba00cd470, params-
type=MAP, params-element-count=2, log-level=WARNING
CAUSED BY ['source.ctf.fs'] (plugins/ctf/common/src/metadata/json/ctf-
2-metadata-stream-parser.cpp:130)
  [1:1 @ 8512 bytes] Invalid fragment #12.
CAUSED BY ['source.ctf.fs'] (plugins/ctf/common/src/metadata/json/ctf-
2-metadata-stream-parser.cpp:367)
  [1:1 @ 17024 bytes] Duplicate clock class fragment with ID `local`.

When running with MIP=0, the CTF 1.8 data does not have this issue (or
the reader ignores the duplicated definitions).

[1] https://github.com/siemens/bt2-ftrace-to-ctf

Attached you will find an AI generated reproducer using just the
babeltrace2 Python bindings.

Best regards,
Felix Moessbauer

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-------------- next part --------------
A non-text attachment was scrubbed...
Name: repro.py
Type: text/x-python3
Size: 4650 bytes
Desc: repro.py
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20260804/e196e5b2/attachment.bin>

From felix.moessbauer at siemens.com  Wed Aug  5 06:16:33 2026
From: felix.moessbauer at siemens.com (MOESSBAUER, Felix)
Date: Wed, 5 Aug 2026 10:16:33 +0000
Subject: babeltrace master: trace-compass is unable to open trace with index
Message-ID: <5eed80a93b79f22f7c30a383f2a7b4d6f7068a97.camel@siemens.com>

Hi,

the babeltrace version from the master branch (65fb4669f) is able to
create LTTng index files. However, these index files seem to be
incompatible with trace-compass.

On loading such a trace, trace-compass (incubator version, 0.18.0-
20260711-0558, or release 12.0.0) issues the following error message:

> Error initializing trace.
> org.eclipse.tracecompass.tmf.core.exceptions.TmfTraceException:
> Failed to allocate mapped byte buffer at 36 of size 416 on a
> file of size 176

I double checked the traces with babeltrace and
https://github.com/eepp/jacquesctf , which are both able to properly
read the traces.

For reproducing, run the
tests/plugins/sink.ctf.fs/test_create_lttng_index.py test and open any
of the generated CTF files in trace-compass. I explicitly tested and
reproduced it with "with-packets-ctf-2" and "no-packets-ctf-2".

The traces itself are valid, which can be proved by removing the index
file and successfully re-opening them in trace-compass.

PS: I'm pretty sure this is a trace-compass bug, but as I'm not a
member of the tracecompass-dev ML, I report it here. Feel free to
forward.

Best regards,
Felix Moessbauer

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany


From arnaud-2.fiorini at polymtl.ca  Wed Aug  5 10:10:05 2026
From: arnaud-2.fiorini at polymtl.ca (Arnaud Fiorini)
Date: Wed, 5 Aug 2026 14:10:05 +0000
Subject: babeltrace master: trace-compass is unable to open trace with
 index
In-Reply-To: <5eed80a93b79f22f7c30a383f2a7b4d6f7068a97.camel@siemens.com>
References: <5eed80a93b79f22f7c30a383f2a7b4d6f7068a97.camel@siemens.com>
Message-ID: <YQBPR0101MB9838D35D912444AEB1C71531E9D32@YQBPR0101MB9838.CANPRD01.PROD.OUTLOOK.COM>

Hi Felix,

There was indeed a bug in how CTF trace index is parsed in Trace Compass. I created a fix in https://github.com/eclipse-tracecompass/org.eclipse.tracecompass/pull/427

If you find another issue in Trace Compass, you can file a bug here instead: https://github.com/eclipse-tracecompass/org.eclipse.tracecompass/issues

Thank you,
Arnaud Fiorini

________________________________
From: MOESSBAUER, Felix via lttng-dev <lttng-dev at lists.lttng.org>
Sent: Wednesday, August 5, 2026 6:16 AM
To: MOESSBAUER, Felix via lttng-dev <lttng-dev at lists.lttng.org>
Subject: babeltrace master: trace-compass is unable to open trace with index

Hi,

the babeltrace version from the master branch (65fb4669f) is able to
create LTTng index files. However, these index files seem to be
incompatible with trace-compass.

On loading such a trace, trace-compass (incubator version, 0.18.0-
20260711-0558, or release 12.0.0) issues the following error message:

> Error initializing trace.
> org.eclipse.tracecompass.tmf.core.exceptions.TmfTraceException:
> Failed to allocate mapped byte buffer at 36 of size 416 on a
> file of size 176

I double checked the traces with babeltrace and
https://github.com/eepp/jacquesctf , which are both able to properly
read the traces.

For reproducing, run the
tests/plugins/sink.ctf.fs/test_create_lttng_index.py test and open any
of the generated CTF files in trace-compass. I explicitly tested and
reproduced it with "with-packets-ctf-2" and "no-packets-ctf-2".

The traces itself are valid, which can be proved by removing the index
file and successfully re-opening them in trace-compass.

PS: I'm pretty sure this is a trace-compass bug, but as I'm not a
member of the tracecompass-dev ML, I report it here. Feel free to
forward.

Best regards,
Felix Moessbauer

--
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.lttng.org/pipermail/lttng-dev/attachments/20260805/d98a9db7/attachment.htm>

From eeppeliteloop at gmail.com  Thu Aug  6 14:45:53 2026
From: eeppeliteloop at gmail.com (Philippe Proulx)
Date: Thu, 6 Aug 2026 14:45:53 -0400
Subject: babeltrace 2.1.2: sink.ctf.fs does not deduplicate identical
 clocks
In-Reply-To: <d0e142586819e25725452b2849308829c38216fb.camel@siemens.com>
References: <d0e142586819e25725452b2849308829c38216fb.camel@siemens.com>
Message-ID: <CAB4xu_3zXGL4a20TRK2m2OwfC7NPqVW6tJvM397er0w6dBwSLw@mail.gmail.com>

On Tue, Aug 4, 2026 at 11:28?AM MOESSBAUER, Felix via lttng-dev
<lttng-dev at lists.lttng.org> wrote:
>
> Hi,
>
> while porting the bt2-ftrace-to-ctf [1] plugin to babeltrace 2.1, I
> noticed that the sink.ctf.fs creates invalid clock definitions if
> multiple stream-classes share the same clock-class. In this case, the
> clock definition is added multiple times to the CTF 2 metadata,
> resulting in the following assertion on read-back:
>
> ERROR:    [Babeltrace CLI] (babeltrace2.c:2705)
>   Command-line error: retcode=1
> CAUSED BY [Source auto-discovery] (autodisc/autodisc.c:493)
>   babeltrace.support-info query failed.
> CAUSED BY [libbabeltrace2] (lib/graph/query-executor.c:233)
>   Component class's "query" method failed: query-exec-
> addr=0x55cba00c12e0, cc-addr=0x55cba00b4100, cc-type=SOURCE, cc-
> name="fs", cc-partial-descr="Read CTF traces from
>   the file sy", cc-is-frozen=0, cc-so-handle-addr=0x55cba00b1930, cc-
> so-handle-path="<...>/build/babeltrace-plugin-ctf.so",
>   object="babeltrace.support-info", params-addr=0x55cba00cd470, params-
> type=MAP, params-element-count=2, log-level=WARNING
> CAUSED BY ['source.ctf.fs'] (plugins/ctf/common/src/metadata/json/ctf-
> 2-metadata-stream-parser.cpp:130)
>   [1:1 @ 8512 bytes] Invalid fragment #12.
> CAUSED BY ['source.ctf.fs'] (plugins/ctf/common/src/metadata/json/ctf-
> 2-metadata-stream-parser.cpp:367)
>   [1:1 @ 17024 bytes] Duplicate clock class fragment with ID `local`.

See <https://review.lttng.org/c/babeltrace/+/18460>.

Let's continue the discussion on Gerrit if need be.

Thank you for the report and reproducer.

Philippe

>
> When running with MIP=0, the CTF 1.8 data does not have this issue (or
> the reader ignores the duplicated definitions).
>
> [1] https://github.com/siemens/bt2-ftrace-to-ctf
>
> Attached you will find an AI generated reproducer using just the
> babeltrace2 Python bindings.
>
> Best regards,
> Felix Moessbauer
>
> --
> Siemens AG
> Linux Expert Center
> Friedrich-Ludwig-Bauer-Str. 3
> 85748 Garching, Germany
>

