LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912024-02-21T17:04:43ZLTTng bugs repository
Redmine Babeltrace - Feature #1410 (New): Add pretty-print sink options to override how to format floatin...https://bugs.lttng.org/issues/14102024-02-21T17:04:43ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Babeltrace 2, just like its predecessor babeltrace 1.5, uses "%g" to print floating point numbers.</p>
<p>It would be useful to let users optionally override the formatting for floating point numbers, perhaps with a pretty print sink option. They could then choose if exponent notation should be used or not, choose the precision, etc.</p> Babeltrace - Bug #1397 (New): reserved identifier violationhttps://bugs.lttng.org/issues/13972023-10-26T18:56:27ZMarkus Elfring
<p>I would like to point out that a few identifiers do eventually not fit to the expected naming convention of the C language standard.<br /><a class="external" href="https://www.securecoding.cert.org/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier">https://www.securecoding.cert.org/confluence/display/c/DCL37-C.+Do+not+declare+or+define+a+reserved+identifier</a></p>
<p>Would you like to adjust your selection for unique names?</p>
Examples:
<ul>
<li>__BT_IN_BABELTRACE_H<br /> <a class="external" href="https://github.com/efficios/babeltrace/blob/8a87cdbd41e2e04b1b64e9959751cdabe72281c1/include/babeltrace2/babeltrace.h#L13-L17">https://github.com/efficios/babeltrace/blob/8a87cdbd41e2e04b1b64e9959751cdabe72281c1/include/babeltrace2/babeltrace.h#L13-L17</a></li>
<li>_BABELTRACE_UTC_H<br /> <a class="external" href="https://github.com/efficios/babeltrace/blob/8a87cdbd41e2e04b1b64e9959751cdabe72281c1/src/compat/utc.h#L7-L8">https://github.com/efficios/babeltrace/blob/8a87cdbd41e2e04b1b64e9959751cdabe72281c1/src/compat/utc.h#L7-L8</a></li>
</ul> Babeltrace - Bug #1389 (New): src.ctf.fs crash with invalid tracehttps://bugs.lttng.org/issues/13892023-09-18T20:16:39ZSimon Marchisimon.marchi@polymtl.ca
<p>Using the attached trace, I get:</p>
<pre>
$ ./src/cli/babeltrace2 trace
09-18 16:15:58.978 335803 335803 E PLUGIN/CTF/MSG-ITER ctf_msg_iter_get_next_message@msg-iter.cpp:2715 [auto-disc-source-ctf-fs] Cannot handle state: msg-it-addr=0x613000000580, state=DSCOPE_EVENT_PAYLOAD_CONTINUE
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:63 Babeltrace 2 library postcondition not satisfied.
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:65 ------------------------------------------------------------------------
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:66 Condition ID: `post:message-iterator-class-next-method:no-error-if-no-error-status`.
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:68 Function: bt_message_iterator_class_next_method().
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:69 ------------------------------------------------------------------------
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:70 Error is:
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:72 Current thread has an error, but user function returned a non-error status: status=OK
09-18 16:15:58.978 335803 335803 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:75 Aborting...
</pre> Babeltrace - Bug #1388 (New): Assertion `this->active_stream_iter == 0` failedhttps://bugs.lttng.org/issues/13882023-09-08T18:57:03ZSimon Marchisimon.marchi@polymtl.ca
<p>Steps:</p>
<ol>
<li><code>lttng create my-session --live</code></li>
<li><code>lttng enable-event -u -a</code></li>
<li><code>lttng start</code></li>
<li><code>./src/cli/babeltrace2 'net://127.0.0.1/host/smarchi-efficios/my-session'</code></li>
<li>Run the hello app from the lttng-ust tests: <code>lttng-ust/tests/hello/hello</code></li>
<li>While events print on the babeltrace terminal, type ctrl-C</li>
</ol>
<p>I get:</p>
<p><code> (╯°□°)╯︵ ┻━┻ /home/smarchi/src/babeltrace/src/plugins/ctf/lttng-live/lttng-live.cpp:214: ~lttng_live_msg_iter(): Assertion `this->active_stream_iter == 0` failed.</code></p> Babeltrace - Bug #1384 (New): Assertion `bt_value_get_type(map) == BT_VALUE_TYPE_MAP` failshttps://bugs.lttng.org/issues/13842023-08-08T18:07:42ZErica Bugden
<p>Hello! I triggered an internal assertion while trying to, presumably incorrectly, query the lttng-live component class.</p>
<a name="Software"></a>
<h1 >Software<a href="#Software" class="wiki-anchor">¶</a></h1>
<ul>
<li>lttng tools: <code>lttng (LTTng Trace Control) 2.14.0-pre - O-Beer - v2.12.0-rc1-1528-g5983bb6d3</code></li>
<li>babeltrace2: <code>Babeltrace 2.1.0-rc1 "Codename TBD" [v1.2.0-3704-gdbea6be2]</code> (configured with plugins, python bindings support)</li>
</ul>
<a name="Procedure"></a>
<h1 >Procedure<a href="#Procedure" class="wiki-anchor">¶</a></h1>
<ul>
<li>Start root session daemon: <code>$sudo lttng-sessiond --daemonize</code></li>
<li>Create live session: <code>$lttng create my-session --live</code></li>
<li>Enable events: <code>$lttng enable-event --kernel sched-switch,sched_process_fork</code></li>
<li>Start tracing <code>$lttng start</code></li>
<li>Run python script: <code>python3 lttng-live.py</code> (see below)
<ul>
<li>Assertion</li>
</ul></li>
</ul>
<a name="Python-script"></a>
<h1 >Python script<a href="#Python-script" class="wiki-anchor">¶</a></h1>
<p>Note: The script is noisy as some code/comments are irrelevant/incorrect/inconsistent. (It's originally based on the query example in the Python bindings documentation.)</p>
<pre>
import bt2
import sys
# Get the `source.ctf.fs` component class from the `ctf` plugin.
# `source.ctf.lttng-live` component class instead
# (list plugins/components with $babeltrace2 list-plugins)
comp_cls = bt2.find_plugin('ctf').source_component_classes['lttng-live']
# The `babeltrace.support-info` query operation expects a `type`
# parameter (set to `directory` here) and an `input` parameter (the
# actual path or string to check, in this case the first command-line
# argument).
#
# See `babeltrace2-query-babeltrace.support-info(7)`.
params = {
'url': 'net://localhost/host/luna/my-session'
}
'''
params = {
'type': 'string',
'input': sys.argv[1],
}
'''
# Create a query executor.
#
# This is the environment in which query operations happens. The
# queried component class has access to this executor, for example to
# retrieve the query operation's logging level.
query_exec = bt2.QueryExecutor(comp_cls, 'sessions',
'inputs=net://localhost/host/luna/my-session')
'''
query_exec = bt2.QueryExecutor(comp_cls, 'babeltrace.support-info',
params)
'''
# Query the component class through the query executor.
#
# This method returns the result.
result = query_exec.query()
# Print the result.
print(result)
# Try to iterate on the trace.
'''
for msg in bt2.TraceCollectionMessageIterator('net://localhost/host/luna/my-session'):
if type(msg) is bt2._EventMessageConst:
print(msg.event.name)
'''
</pre>
<p>If I remember correctly, <strong>the script line change that triggered the assertion was expressing the query parameters directly as a string</strong> (rather than a dictionary). As in this:</p>
<pre>
query_exec = bt2.QueryExecutor(comp_cls, 'sessions',
'inputs=net://localhost/host/luna/my-session')
</pre>
<p>instead of this:</p>
<pre>
params = {
'url': 'net://localhost/host/luna/my-session'
}
query_exec = bt2.QueryExecutor(comp_cls, 'sessions',
params)
</pre>
<a name="Output"></a>
<h1 >Output<a href="#Output" class="wiki-anchor">¶</a></h1>
<pre>
erica@luna:~$ python3 lttng-live.py
(╯°□°)╯︵ ┻━┻ param-validation.c:196: validate_map_value(): Assertion `bt_value_get_type(map) == BT_VALUE_TYPE_MAP` failed.
Aborted (core dumped)
</pre> Babeltrace - Bug #1374 (New): Babeltrace fails to read trace with no data stream type ID when the...https://bugs.lttng.org/issues/13742023-04-26T17:57:32ZErica Bugden
<p>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.</p>
<a name="Does-this-need-to-be-fixed"></a>
<h3 >Does this need to be fixed?<a href="#Does-this-need-to-be-fixed" class="wiki-anchor">¶</a></h3>
<p>This was first reported as a barectf issue <a class="external" href="https://github.com/efficios/barectf/issues/28">https://github.com/efficios/barectf/issues/28</a> , 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.</p>
<p>The superfluous metadata information need not prevent the trace from being parsed. For example, yactfr <a class="external" href="https://github.com/eepp/yactfr">https://github.com/eepp/yactfr</a> is able to read the trace. However, considering that:</p>
<ul>
<li>At least two CTF readers (babeltrace and Trace Compass) cannot read the trace, and</li>
<li>It is easy to fix in barectf (Proposed fix: <a class="external" href="https://review.lttng.org/c/barectf/+/9868">https://review.lttng.org/c/barectf/+/9868</a> )</li>
</ul>
<p>this is not a high priority issue in babeltrace.</p>
<a name="Context"></a>
<h1 >Context<a href="#Context" class="wiki-anchor">¶</a></h1>
<p>- Background and reproducer: barectf github issue <a class="external" href="https://github.com/efficios/barectf/issues/28">https://github.com/efficios/barectf/issues/28</a> <br />- Background and specification discussion: barectf fix <a class="external" href="https://review.lttng.org/c/barectf/+/9868">https://review.lttng.org/c/barectf/+/9868</a></p> Babeltrace - Bug #1364 (New): CTF: Mismatching variant and tag selector and field names causes a ...https://bugs.lttng.org/issues/13642022-11-25T22:09:40ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Running <code>200e2a8d2</code>, decoding a CTF trace that has mismatching variant field and enumeration mapping names results in a crash:</p>
<pre>
❯ babeltrace ~/lttng-traces/auto-20221125-164416/ust/uid/1000/64-bit
(╯°□°)╯︵ ┻━┻ ctf-meta-translate.cpp:276: ctf_field_class_variant_to_ir(): Assertion `mapping` failed.
[1] 215518 IOT instruction (core dumped) babeltrace ~/lttng-traces/auto-20221125-164416/ust/uid/1000/64-bit
</pre>
<pre>
#0 0x00007fc99129964c in ?? () from /usr/lib/libc.so.6
#1 0x00007fc991249958 in raise () from /usr/lib/libc.so.6
#2 0x00007fc99123353d in abort () from /usr/lib/libc.so.6
#3 0x00007fc990ec3bf5 in bt_common_abort () at common.c:2111
#4 0x00007fc990f1d298 in bt_common_assert_failed (file=0x7fc990f28fbb "ctf-meta-translate.cpp",
line=276, func=0x7fc990f290e8 "ctf_field_class_variant_to_ir",
assertion=0x7fc990f2913f "mapping") at assert.c:40
#5 0x00007fc990ed1612 in ctf_field_class_variant_to_ir (fc=0x55568bfbf780, ctx=0x7ffd71c5f7f0)
at ctf-meta-translate.cpp:276
#6 ctf_field_class_to_ir (ctx=ctx@entry=0x7ffd71c5f7f0, fc=0x55568bfbf780)
at ctf-meta-translate.cpp:390
#7 0x00007fc990ed1883 in translate_struct_field_class_members (with_header_prefix=<optimized out>,
context_fc=<optimized out>, ir_fc=<optimized out>, fc=<optimized out>, ctx=<optimized out>)
at ctf-meta-translate.cpp:159
#8 ctf_field_class_struct_to_ir (fc=0x55568bf13490, ctx=0x7ffd71c5f7f0)
at ctf-meta-translate.cpp:173
#9 ctf_field_class_to_ir (ctx=ctx@entry=0x7ffd71c5f7f0, fc=0x55568bf13490)
at ctf-meta-translate.cpp:381
#10 0x00007fc990ed2464 in scope_ctf_field_class_to_ir (ctx=0x7ffd71c5f7f0)
at ctf-meta-translate.cpp:453
#11 ctf_stream_class_to_ir (ctx=0x7ffd71c5f7f0) at ctf-meta-translate.cpp:552
#12 ctf_trace_class_translate (self_comp=<optimized out>, ir_tc=<optimized out>, tc=0x55568bf14150)
at ctf-meta-translate.cpp:641
#13 0x00007fc990eec028 in ctf_visitor_generate_ir_visit_node (ctx=0x55568bf3a620,
node=0x55568bf14040) at visitor-generate-ir.cpp:4776
#14 0x00007fc990ed965a in ctf_metadata_decoder_append_content (mdec=0x55568bf0b340,
fp=<optimized out>) at decoder.cpp:326
#15 0x00007fc990f0caaa in ctf_fs_metadata_set_trace_class (self_comp=self_comp@entry=0x55568bf13970,
ctf_fs_trace=ctf_fs_trace@entry=0x55568bf09da0, config=config@entry=0x55568bf0b478)
at metadata.cpp:103
#16 0x00007fc990f098b8 in ctf_fs_trace_create (log_level=BT_LOGGING_LEVEL_WARNING,
metadata_config=0x55568bf0b478, name=0x0,
path=0x55568bf0b4a0 "/home/jgalar/lttng-traces/auto-20221125-164416/ust/uid/1000/64-bit",
self_comp_class=0x0, self_comp=0x55568bf13970) at fs.cpp:1027
#17 ctf_fs_component_create_ctf_fs_trace_one_path (self_comp_class=0x0, self_comp=0x55568bf13970,
traces=0x55568bf35620, trace_name=0x0, path_param=<optimized out>, ctf_fs=0x55568bf0b460)
at fs.cpp:1129
#18 ctf_fs_component_create_ctf_fs_trace (ctf_fs=ctf_fs@entry=0x55568bf0b460,
paths_value=<optimized out>, trace_name_value=<optimized out>,
self_comp=self_comp@entry=0x55568bf13970, self_comp_class=self_comp_class@entry=0x0)
at fs.cpp:2002
#19 0x00007fc990f0c3c3 in ctf_fs_create (self_comp_src=0x55568bf13970, params=0x55568bf0d9a0)
at fs.cpp:2278
#20 ctf_fs_init (self_comp_src=0x55568bf13970, config=config@entry=0x0,
params=params@entry=0x55568bf0d9a0, init_method_data=init_method_data@entry=0x0) at fs.cpp:2311
#21 0x00007fc991568b4d in add_component_with_init_method_data (graph=graph@entry=0x55568bf13800,
comp_cls=comp_cls@entry=0x55568bf32970,
init_method=0x7fc990f0c320 <ctf_fs_init(bt_self_component_source*, bt_self_component_source_configuration*, bt_value const*, void*)>, name=name@entry=0x55568bf0d910 "auto-disc-source-ctf-fs",
params=params@entry=0x55568bf0d9a0, init_method_data=init_method_data@entry=0x0,
log_level=BT_LOGGING_LEVEL_WARNING, user_component=0x7ffd71c5fd00,
api_func=0x7fc9915a9660 <__func__.13> "bt_graph_add_source_component",
init_method_name=0x7fc9915aa860 "bt_component_class_source_initialize_method") at graph.c:1048
#22 0x00007fc99156aaae in add_source_component_with_initialize_method_data (
api_func=0x7fc9915a9660 <__func__.13> "bt_graph_add_source_component", component=0x7ffd71c5fd00,
log_level=BT_LOGGING_LEVEL_WARNING, init_method_data=0x0, params=0x55568bf0d9a0,
name=0x55568bf0d910 "auto-disc-source-ctf-fs", comp_cls=0x55568bf32970, graph=0x55568bf13800)
at graph.c:1127
#23 bt_graph_add_source_component (graph=0x55568bf13800, comp_cls=comp_cls@entry=0x55568bf32970,
name=0x55568bf0d910 "auto-disc-source-ctf-fs", params=0x55568bf0d9a0,
log_level=BT_LOGGING_LEVEL_WARNING, component=component@entry=0x7ffd71c5fd00) at graph.c:1152
#24 0x000055568aa845d6 in cmd_run_ctx_create_components_from_config_components (
ctx=ctx@entry=0x7ffd71c5fde0, cfg_components=<optimized out>) at babeltrace2.c:2259
#25 0x000055568aa7ffe4 in cmd_run_ctx_create_components (ctx=0x7ffd71c5fde0) at babeltrace2.c:2355
#26 cmd_run (cfg=0x55568bf14390) at babeltrace2.c:2469
--Type <RET> for more, q to quit, c to continue without paging--
#27 main (argc=<optimized out>, argv=<optimized out>) at babeltrace2.c:2679
</pre>
<p>The relevant part of the trace's metadata is as-follows where you can see "_none" and "none" don't match.<br /><pre>
event.context := struct {
enum : integer { size = 8; align = 8; signed = true; } {
"none" = 0,
"_int8" = 1,
"_int16" = 2,
"_int32" = 3,
"_int64" = 4,
"_uint8" = 5,
"_uint16" = 6,
"_uint32" = 7,
"_uint64" = 8,
"_float" = 9,
"_double" = 10,
"_string" = 11
} __app_lol_gooo_tag;
variant <__app_lol_gooo_tag> {
struct {} _none;
integer { size = 8; align = 8; signed = true; } _int8;
integer { size = 16; align = 8; signed = true; } _int16;
integer { size = 32; align = 8; signed = true; } _int32;
integer { size = 64; align = 8; signed = true; } _int64;
integer { size = 8; align = 8; } _uint8;
integer { size = 16; align = 8; } _uint16;
integer { size = 32; align = 8; } _uint32;
integer { size = 64; align = 8; } _uint64;
floating_point { align = 8; mant_dig = 24; exp_dig = 8; } _float;
floating_point { align = 8; mant_dig = 53; exp_dig = 11; } _double;
string _string;
} __app_lol_gooo;
};
</pre></p>
<p>Arguably, the CTF 1.8.3 specification says that:<br /><pre>
Each variant type selector possess a field name, which is a unique identifier within the variant. The identifier is not allowed to use any reserved keyword. Replacing reserved keywords with underscore-prefixed field names is recommended. Fields starting with an underscore should have their leading underscore removed by the CTF trace readers.
</pre></p>
<p>As the term "should" is used, this presumably means that the reader could choose to match those or not. I can confirm that Babeltrace 1.5 also fails (but doesn't crash) so it seems reasonable to require an exact match.</p>
<p>I'm joining a trace that reproduces the issue.</p> Babeltrace - Bug #1348 (New): Assertion failure when passing `smalltrace` CTF test trace twice to...https://bugs.lttng.org/issues/13482022-03-11T21:29:01ZFrancis Deslauriersfrancis.deslauriers@efficios.com
<p>Command used:<br /><pre>
src/cli/babeltrace2 tests/data/ctf-traces/succeed/smalltrace tests/data/ctf-traces/succeed/smalltrace
</pre></p>
<p>The same issue can be reproduce with the <code>env-warning</code> test trace.</p>
<p>Error print out:<br /><pre>
03-11 16:21:26.766 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:64 Babeltrace 2 library precondition not satisfied.
03-11 16:21:26.767 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:66 ------------------------------------------------------------------------
03-11 16:21:26.767 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:67 Condition ID: `pre:self-component-source-add-output-port:output-port-is-unique`.
03-11 16:21:26.767 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:69 Function: bt_self_component_source_add_output_port().
03-11 16:21:26.767 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:70 ------------------------------------------------------------------------
03-11 16:21:26.767 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:71 Error is:
03-11 16:21:26.767 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:73 Output port name is not unique: name="2a6422d0-6cee-11e0-8c08-cb07d7b3a564 | 0 | /home/frdeso/projets/babeltrace/tests/data/ctf-traces/succeed/smalltrace/dummystream", comp-addr=0x5555555961c0, comp-name="auto-disc-source-ctf-fs", comp-log-level=WARNING, comp-class-type=SOURCE, comp-class-name="fs", comp-class-partial-descr="Read CTF traces from the file sy"
03-11 16:21:26.767 2579249 2579249 F LIB/ASSERT-COND bt_lib_assert_cond_failed@assert-cond.c:76 Aborting...
Program received signal SIGABRT, Aborted.
</pre></p>
<p>GDB stack trace:<br /><pre>
#0 0x00007ffff7bd003b in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff7baf859 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff7ee32e5 in bt_common_abort () at common.c:2111
#3 0x00007ffff7ee408a in bt_lib_assert_cond_failed (cond_type=cond_type@entry=0x7ffff7f521c4 "pre", func=func@entry=0x7ffff7f59fc0 <__func__.17520> "bt_self_component_source_add_output_port", id_suffix=id_suffix@entry=0x7ffff7f59e51 "output-port-is-unique", fmt=fmt@entry=0x7ffff7f59ec8 "Output port name is not unique: name=\"%s\", %![comp-]c") at assert-cond.c:77
#4 0x00007ffff7f00410 in bt_self_component_source_add_output_port (self_comp=0x5555555961c0, name=0x5555555d01f0 "2a6422d0-6cee-11e0-8c08-cb07d7b3a564 | 0 | /home/frdeso/projets/babeltrace/tests/data/ctf-traces/succeed/smalltrace/dummystream", user_data=0x5555555d8440, self_port=0x0) at component-source.c:127
#5 0x00007ffff7ab7622 in create_one_port_for_trace (ctf_fs=0x555555596360, ctf_fs_trace=0x555555594d40, ds_file_group=0x5555555cb8c0, self_comp_src=0x5555555961c0) at fs.cpp:436
#6 0x00007ffff7ab735f in create_ports_for_trace (ctf_fs=0x555555596360, ctf_fs_trace=0x555555594d40, self_comp_src=0x5555555961c0) at fs.cpp:469
#7 0x00007ffff7ab2fc8 in ctf_fs_create (params=0x5555555bc2e0, self_comp_src=0x5555555961c0) at fs.cpp:2287
#8 0x00007ffff7ab2ebc in ctf_fs_init (self_comp_src=0x5555555961c0, config=0x0, params=0x5555555bc2e0, init_method_data=0x0) at fs.cpp:2311
#9 0x00007ffff7f05bb3 in add_component_with_init_method_data (graph=graph@entry=0x5555555bd240, comp_cls=comp_cls@entry=0x5555555b80e0, init_method=0x7ffff7ab2e90 <ctf_fs_init(bt_self_component_source*, bt_self_component_source_configuration*, bt_value const*, void*)>, name=name@entry=0x5555555bc2b0 "auto-disc-source-ctf-fs", params=params@entry=0x5555555bc2e0, init_method_data=init_method_data@entry=0x0, log_level=BT_LOGGING_LEVEL_WARNING, user_component=0x7fffffffe0a0, api_func=0x7ffff7f5c400 <__func__.18097> "bt_graph_add_source_component", init_method_name=0x7ffff7f5ca48 "bt_component_class_source_initialize_method") at graph.c:1048
#10 0x00007ffff7f0654f in add_source_component_with_initialize_method_data (graph=0x5555555bd240, comp_cls=0x5555555b80e0, name=0x5555555bc2b0 "auto-disc-source-ctf-fs", params=0x5555555bc2e0, init_method_data=0x0, log_level=BT_LOGGING_LEVEL_WARNING, component=0x7fffffffe0a0, api_func=0x7ffff7f5c400 <__func__.18097> "bt_graph_add_source_component") at graph.c:1127
#11 0x00007ffff7f0932d in bt_graph_add_source_component (graph=<optimized out>, comp_cls=comp_cls@entry=0x5555555b80e0, name=<optimized out>, params=<optimized out>, log_level=<optimized out>, component=component@entry=0x7fffffffe0a0) at graph.c:1152
#12 0x0000555555561c42 in cmd_run_ctx_create_components_from_config_components (ctx=ctx@entry=0x7fffffffe170, cfg_components=<optimized out>, cfg_components=<optimized out>) at babeltrace2.c:2259
#13 0x000055555555cda9 in cmd_run_ctx_create_components (ctx=0x7fffffffe170) at babeltrace2.c:2355
#14 cmd_run (cfg=0x55555559fc70) at babeltrace2.c:2469
#15 main (argc=<optimized out>, argv=<optimized out>) at babeltrace2.c:2679
</pre></p>
<p>Commit:<br /><pre>
commit 53a47a3f01d6bfa4e940e1943e7645cb89d04cd5 (HEAD -> master, review/master, origin/master, origin/HEAD, eepp,simark/master)
Author: Michael Jeanson <mjeanson@efficios.com>
Date: Wed Mar 2 13:25:05 2022 -0500
fix: add dependency between cli bin and plugins when built-in
</pre></p> Babeltrace - Bug #1346 (New): sink.ctf.fs: Assertion failure while encoding length FC of dynamic ...https://bugs.lttng.org/issues/13462022-02-15T16:14:22ZFrancis Deslauriersfrancis.deslauriers@efficios.com
<p>I witnessed this issue while working on the CTF2 support of the sink.ctf.fs component class.</p>
<pre>
(╯°□°)╯︵ ┻━┻ translate-trace-ir-to-ctf-ir.cpp:283: create_relative_field_ref(): Assertion `bt_field_path_item_get_type(fp_item) == BT_FIELD_PATH_ITEM_TYPE_INDEX` failed.
</pre>
<p>The problem is triggered when a length field class of a dynamic array field class is contained within an element of a static array field class. Both dynamic array and its length are in the same element within the static array.</p>
<p>I attached the source of a Python plugin that reproduces this issue.</p>
<p>I can reproduce the issue with the following command:<br /><pre>
babeltrace2 --plugin-path=/home/frdeso/projets/babeltrace-fun-plugins/my-first-components/ -c source.reprod.MyFirstSource -c sink.ctf.fs -p path=\"ici\"
</pre></p>
<p>Here is the full stack trace of the assertion failure:<br /><pre>
#3 0x00007ffff6534c11 in bt_common_assert_failed (file=0x7ffff654c62c "translate-trace-ir-to-ctf-ir.cpp", line=283, func=0x7ffff654cf00 "create_relative_field_ref", assertion=0x7ffff654cf3a "bt_field_path_item_get_type(fp_item) == BT_FIELD_PATH_ITEM_TYPE_INDEX") at assert.c:40
#4 0x00007ffff6505624 in create_relative_field_ref (ctx=0x7fffffffe0f8, tgt_ir_field_path=0x5555555980a0, tgt_field_ref=0x555555599900, user_tgt_fc=0x0) at translate-trace-ir-to-ctf-ir.cpp:283
#5 0x00007ffff650529b in resolve_field_class (ctx=0x7fffffffe0f8, tgt_ir_field_path=0x5555555980a0, tgt_field_ref=0x555555599900, create_before=0x55555559b420, user_tgt_fc=0x0) at translate-trace-ir-to-ctf-ir.cpp:510
#6 0x00007ffff6503ccb in translate_dynamic_array_field_class (ctx=0x7fffffffe0f8) at translate-trace-ir-to-ctf-ir.cpp:1087
#7 0x00007ffff65035b7 in translate_field_class (ctx=0x7fffffffe0f8) at translate-trace-ir-to-ctf-ir.cpp:1191
#8 0x00007ffff6502e5a in translate_structure_field_class_members (ctx=0x7fffffffe0f8, struct_fc=0x55555559b2f0, ir_fc=0x5555556fed80) at translate-trace-ir-to-ctf-ir.cpp:615
#9 0x00007ffff650398a in translate_structure_field_class (ctx=0x7fffffffe0f8) at translate-trace-ir-to-ctf-ir.cpp:638
#10 0x00007ffff6503570 in translate_field_class (ctx=0x7fffffffe0f8) at translate-trace-ir-to-ctf-ir.cpp:1187
#11 0x00007ffff6503b18 in translate_static_array_field_class (ctx=0x7fffffffe0f8) at translate-trace-ir-to-ctf-ir.cpp:1061
#12 0x00007ffff650358f in translate_field_class (ctx=0x7fffffffe0f8) at translate-trace-ir-to-ctf-ir.cpp:1189
#13 0x00007ffff6502e5a in translate_structure_field_class_members (ctx=0x7fffffffe0f8, struct_fc=0x55555559b120, ir_fc=0x5555557500d0) at translate-trace-ir-to-ctf-ir.cpp:615
#14 0x00007ffff6502819 in translate_scope_field_class (ctx=0x7fffffffe0f8, scope=BT_FIELD_PATH_SCOPE_EVENT_PAYLOAD, fc=0x55555559b028, ir_fc=0x5555557500d0) at translate-trace-ir-to-ctf-ir.cpp:1446
#15 0x00007ffff6501ab9 in translate_event_class (fs_sink=0x555555598510, sc=0x55555559ae80, ir_ec=0x5555557166e0, out_ec=0x7fffffffe1e8) at translate-trace-ir-to-ctf-ir.cpp:1503
#16 0x00007ffff6501955 in try_translate_event_class_trace_ir_to_ctf_ir (fs_sink=0x555555598510, sc=0x55555559ae80, ir_ec=0x5555557166e0, out_ec=0x7fffffffe1e8) at translate-trace-ir-to-ctf-ir.cpp:1532
#17 0x00007ffff64fe4a4 in handle_event_msg (fs_sink=0x555555598510, msg=0x55555559a530) at fs-sink.cpp:266
#18 0x00007ffff64fe082 in ctf_fs_sink_consume (self_comp=0x555555598480) at fs-sink.cpp:957
</pre></p> Babeltrace - Feature #1336 (New): Improve usability of error messageshttps://bugs.lttng.org/issues/13362021-11-30T16:03:37ZMatthew Khouzam
<p>At the moment babeltrace2's error messages are as follows</p>
<p>$ babeltrace2 trace -o ctf<br /><em>11-30 09:45:52.878 16686 16686 E CLI/CFG-CLI-ARGS <a class="email" href="mailto:bt_config_convert_from_args@babeltrace2-cfg-cli-args.c">bt_config_convert_from_args@babeltrace2-cfg-cli-args.c</a>:3971 --output-format=ctf specified without --output (trace output path).<br />11-30 09:45:52.878 16686 16686 E CLI <a class="email" href="mailto:main@babeltrace2.c">main@babeltrace2.c</a>:2663 Command-line error: retcode=1</em></p>
<p><em><strong>ERROR:</strong></em> [ <strong>Babeltrace CLI</strong> ] ( <em>babeltrace2.c:2663</em> )<br /> Command-line error: retcode=1<br /><em><strong>CAUSED BY</strong></em> [ <strong>Babeltrace CLI</strong> ] ( <em>babeltrace2-cfg-cli-args.c:3971</em> )<br /> --output-format=ctf specified without --output (trace output path).</p>
<p>where <strong>bold</strong> is bold and <em>italics</em> are colored.</p>
<p>The part the user needs to see in order to solve their issue is the last line and is one of the few items not highlighted:</p>
<pre><code>--output-format=ctf specified without --output (trace output path).</code></pre>
<p>This line is difficult to find in the wall of text if you don't know what you are looking for.</p>
<p>I would recommend</p>
<p>$ babeltrace2 trace -o ctf<br />babeltrace2: --output-format=ctf specified without --output (trace output path).</p>
<p>and</p>
<p>$babeltrace2 trace -o ctf -v<br /><em>11-30 09:45:52.878 16686 16686 E CLI/CFG-CLI-ARGS <a class="email" href="mailto:bt_config_convert_from_args@babeltrace2-cfg-cli-args.c">bt_config_convert_from_args@babeltrace2-cfg-cli-args.c</a>:3971 --output-format=ctf specified without --output (trace output path).<br />11-30 09:45:52.878 16686 16686 E CLI <a class="email" href="mailto:main@babeltrace2.c">main@babeltrace2.c</a>:2663 Command-line error: retcode=1</em></p>
<p><em><strong>ERROR:</strong></em> [ <strong>Babeltrace CLI</strong> ] ( <em>babeltrace2.c:2663</em> )<br /> Command-line error: retcode=1<br /><em><strong>CAUSED BY</strong></em> [ <strong>Babeltrace CLI</strong> ] ( <em>babeltrace2-cfg-cli-args.c:3971</em> )<br /> --output-format=ctf specified without --output (trace output path).</p> Babeltrace - Feature #1300 (New): babeltrace2 lacks knowledge of bitwise enum produced by lttng-m...https://bugs.lttng.org/issues/13002021-03-23T17:41:47ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>This is a follow up on <a class="external" href="https://review.lttng.org/c/babeltrace/+/3045">https://review.lttng.org/c/babeltrace/+/3045</a> now that end users are starting to contact us wondering why up-to-date lttng and babeltrace2 show incomplete information for bitwise enums.</p>
<p>I think we should implement a better stop-gap solution while awaiting CTF2. I recommend that we specialize the babeltrace2 CTF input plugin to detect traces produced by the lttng-modules kernel tracer, for specific known (hardcoded) events and fields which have a bitwise enum semantic, and use this hardcoded knowledge to print the correct bitwise enum to the end user rather than "<unknown>".</p>
<p>This should ensure the current producer/consumer tools work well together (show complete information about those bitwise enums) without requiring to modify tons of documentation about the specific flags needed for bt2 to handle lttng traces appropriately. And this would not lead to misleading scenarios where we print an unknown value as a bitwise enum by mistake.</p>
<p>Hardcoded producer detection/event/fields is of course a last resort solution awaiting proper self-description in the upcoming CTF2 spec.</p> Babeltrace - Feature #1233 (New): Python: Add __str__ to Message types, and perhaps other typeshttps://bugs.lttng.org/issues/12332020-02-17T21:49:43ZSimon Marchisimon.marchi@polymtl.ca
<p>Example use case: I assume that when implementing a sink, people will print() the messages they receive at first. It would be nice if the output was more useful than:</p>
<pre>
<bt2.message._EventMessage object @ 0x607000006530>
<bt2.message._PacketEndMessage object @ 0x6070000065a0>
<bt2.message._PacketBeginningMessage object @ 0x607000006760>
<bt2.message._PacketBeginningMessage object @ 0x6070000049a0>
<bt2.message._EventMessage object @ 0x607000004c40>
<bt2.message._EventMessage object @ 0x607000006a00>
<bt2.message._PacketEndMessage object @ 0x607000006a70>
<bt2.message._PacketBeginningMessage object @ 0x607000006c30>
<bt2.message._EventMessage object @ 0x607000006530>
<bt2.message._PacketEndMessage object @ 0x607000004cb0>
<bt2.message._PacketBeginningMessage object @ 0x607000004e70>
</pre> Babeltrace - Feature #1226 (New): Allow making graph execution more "event-based"https://bugs.lttng.org/issues/12262020-02-17T21:10:09ZSimon Marchisimon.marchi@polymtl.ca
<p>Currently, when using the lttng-live source component class, the source component will return TRY_AGAIN if it has no messages to return but the connection is still open. The graph will return TRY_AGAIN to the user, which can then run the graph again to retry. The source component might have some data available, or it might also return TRY_AGAIN again. This effectively constitutes a busy loop, consuming CPU to check if new data is available.</p>
<p>It would be better to have the process block on a syscall if there's nothing to consume, and be woken up when some data arrives. Here's how I would see it:</p>
<p>1. A source that may return TRY_AGAIN would register a file descriptor to be used as an asynchronous event source, along with a callback<br />2. When a sink's consume method returns TRY_AGAIN, that sink is placed in the "inactive sinks" list<br />3. If there are no active sinks, bt_graph_run (or some new function) would <code>poll</code> all event sources, waiting for one to become readable.<br />4. It would call the callback associated to the event source(s) that became readable<br />5. The source component would send some kind of signal downstream that would trickle down to the sinks that previously became inactive, those sinks would inform the graph, who would put them back in the "active" list</p>
<p>Of course, many problems come to mind, such as how to deal with portability, multiple sinks where one keeps producing and one that becomes inactive and active again (how do you make sure not to starve the one that became inactive), how to evolve the API to include that without breaking any existing behavior, etc.</p> Babeltrace - Feature #1164 (New): Write a plugin to anonymize traceshttps://bugs.lttng.org/issues/11642018-05-17T16:14:29ZGeneviève Bastiengbastien+lttng@versatic.net
<p>Here's a feature that was discussed during last hack-a-thon:</p>
<p>Write a babeltrace plugin that would allow to remove all internal information from the trace, so that the trace can be sent for analysis without exposing internal information.</p>
<p>The kind of information to anonymize (not exhaustive, more thoughts need to be put in it):</p>
<ul>
<li>In the metadata: host names</li>
</ul>
<ul>
<li>IP addresses: Change them for dummy IPs</li>
</ul>
<ul>
<li>File names</li>
</ul>
<ul>
<li>Process names?</li>
</ul>
<p>The plugin should keep a mapping of the anonymized information so that results can be mapped back to original data.</p> Babeltrace - Feature #1045 (New): Wire up debug info on lttng_ust_cyg_profile event fieldshttps://bugs.lttng.org/issues/10452016-07-13T14:53:52ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>#lttng paste</p>
<p>09:56 < rnsanchez> is there a default procedure for "hydrating" instrument-functions traces like this?<br />09:56 < rnsanchez> [13:54:09.866652414] (+0.000001178) priminho lttng_ust_cyg_profile:func_exit: { cpu_id = 1 }, { addr = 0x46BB90, call_site = 0x46BF7B }<br />09:56 < rnsanchez> (kind of replacing the addr with their proper symbols)<br />09:57 < milian> rnsanchez: I'm not an lttng dev, but could imagine that one would be able to write that by analyzing mmap + openat to find the offset into a library, which you can then feed into addr2line, or libdw/libbacktrace<br />09:59 < rnsanchez> I could propably pass it (babeltrace) through some script to do that. but since the trace is huge (and this is not even a "real" trace), I was wondering if there is a better way to do that<br />09:59 < milian> I'd also be interested in that<br />10:00 < rnsanchez> well maybe there is one. building a symbol-table cache for the known things (a binary of special interest) and then feeding babeltrace through awk, replacing the symbols found with their names<br />10:01 < rnsanchez> some would miss, of course, but perhaps a good amount would help<br />10:46 < Compudj> rnsanchez, milian: currently, babeltrace is a bit "hardwired" to the "ip" context for symbol resolution<br />10:46 < Compudj> but all the infrastructure code is there<br />10:49 < Compudj> see babeltrace: formats/ctf-text/types/integer.c<br />10:49 < Compudj> there is a call to ctf_text_integer_write_debug_info<br />10:50 < Compudj> implemented in include/babeltrace/trace-debug-info.h<br />10:50 < Compudj> it checks if integer_definition->debug_info_src is non-null<br />10:51 < Compudj> this is wired up in lib/debug-info.c register_event_debug_infos()<br />10:51 < Compudj> it is where it is tied to the "ip" context<br />10:51 < Compudj> it should be extended to be tied to the lttng_ust_cyg_profile event fields too</p>