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> LTTng-modules - Feature #1395 (New): Add probe for io_uringhttps://bugs.lttng.org/issues/13952023-10-10T15:23:31ZKienan Stewart
<p>Requested on the lltng-dev list. C.f. <a class="external" href="https://lists.lttng.org/pipermail/lttng-dev/2023-October/030640.html">https://lists.lttng.org/pipermail/lttng-dev/2023-October/030640.html</a></p> LTTng-tools - Feature #1391 (New): Add 'enable-events' as a special argument to lttng-toolshttps://bugs.lttng.org/issues/13912023-09-26T13:39:06ZMatthew Khouzammatthew.khouzam@ericsson.com
<p>I have observed users trying to enable events by running</p>
<pre>
lttng enable-events -a -u
</pre><br /> or<br /><pre>
lttng enable-events -a -k
</pre><br /> with the logic that they are enabling several events. Then they panic when there is an error message. As this is an understandable issue, maybe it would be worth giving a clearer message: "It looks like you are trying to run 'enable-event'" or something similar. Userspace RCU - Feature #1368 (New): Integrate RCU implementation from libside into liburcuhttps://bugs.lttng.org/issues/13682023-02-14T14:26:10ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>libside features a multi-domain RCU implementation semantically similar to the Linux kernel's SRCU's implementation. It tracks grace periods with per-cpu counters rather than per-thread state.</p>
<p><a class="external" href="https://github.com/efficios/libside/blob/master/src/rcu.h">https://github.com/efficios/libside/blob/master/src/rcu.h</a><br /><a class="external" href="https://github.com/efficios/libside/blob/master/src/rcu.c">https://github.com/efficios/libside/blob/master/src/rcu.c</a></p>
<p>It is somewhat different from other urcu flavors because it supports multiple domains, whereas current liburcu flavors only have a single domain per process.</p>
<p>We would have to think thoroughly about the impacts of supporting multiple domains on other parts of liburcu such as the call_rcu worker thread. The worker thread would either have to be able to synchronize with multiple RCU domains, or we would have to require each worker thread to be associated with a single RCU domain.</p>
<p>Similar concerns arise with respect to data structures such as rculfhash which take a urcu flavor as parameter: with per-domain flavor, those would have to be associated with a specific RCU domain in addition to the flavor.</p> LTTng - Feature #1366 (New): static library aka liblttng-ust.ahttps://bugs.lttng.org/issues/13662023-01-30T21:57:28Zkasper k
<p><a class="external" href="https://github.com/lttng/lttng-ust/tree/v2.13.5#building-steps">https://github.com/lttng/lttng-ust/tree/v2.13.5#building-steps</a></p>
<p>reads</p>
<blockquote>
<p>LTTng-UST needs to be a shared library, <em>even if</em> the tracepoint probe provider is statically linked into the application.</p>
</blockquote>
<p>is it "impossible" to produce a static variant (<code>liblttng-ust.a</code>) which the user can link with their <code>my_code_with_provider_probe_and_main_entrypoint.o</code> and <code>-static</code> flag to get a statically linked executable?</p>
<p>in case it is technically possible but deemed uninteresting scenario by devs, please know that <em>most</em> libraries in distro packages provide static lib option (openssl and icu are two big names but list goes on and on) and there are use-cases which require this kind of isolation.</p> LTTng - Feature #1347 (New): Codename for 2.14https://bugs.lttng.org/issues/13472022-03-01T20:27:38ZMichael Jeansonmjeanson@efficios.com
<p>What should the codename of the LTTng 2.14 release be?</p>
<p>Must be a micro-brewed Quebec beer and start with a "O".</p> LTTng-tools - Feature #1341 (New): Introduce "--shm-path-ust" to clarify use vs documentationhttps://bugs.lttng.org/issues/13412021-12-07T20:53:52ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Considering that the "--shm-path" argument is documented as applying to all domains, but that currently the kernel domain does not support this argument, it leads us to a situation where users may budget their NVRAM for the space needed only for UST buffers, and eventually upgrade to a new LTTng version which would implement kernel support for shm-path. They would then face issues given the lack of available space.</p>
<p>I would recommend to add a new "--shm-path-ust" argument as an alias to "--shm-path", but document that it only applies to the UST domain. This way, users wishing to budget their NVRAM space only for UST tracing, but still perform kernel tracing in the same session, will be able to do so.</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> LTTng - Feature #1288 (New): Combine all per-cpu shm areas for a channel into a single filehttps://bugs.lttng.org/issues/12882020-10-13T15:39:03ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>On the reason for having one shm file per cpu (per channel/per uid/per session): having one file per cpu is mainly done to facilitate NUMA-local memory allocation. That being said, I wonder if as a future improvement we could combine all per-cpu buffers into a single shm file, and issue numa_set_preferred piecewise when mmapping regions of the files. This would lessen the number of file descriptors needed by a significant amount. I suspect it would work, but we'd need to do some prototyping to validate this approach first.</p> LTTng-tools - Feature #1287 (New): Use abstract sockets for lttng-consumerd UST shared memory fileshttps://bugs.lttng.org/issues/12872020-10-13T15:35:32ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Abstract sockets (unix(7)) are not tied to the filesystem, and are available since Linux 2.2.</p>
<p>Those are Linux-specific.</p>
<p>Those are the same as regular unix domain but their first character of path is NULL. They have the benefit of not requiring unlinking of files left behind.</p>
<p>We could use those abstract sockets in lttng-consumerd on Linux.</p> LTTng - Feature #1269 (New): Document clearly the versioning scheme of lttng-projects.https://bugs.lttng.org/issues/12692020-05-22T19:42:08ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Correct me if I am wrong but it is an "unwritten" rule that we follow semver [1]. Some organization might appreciate that we state clearly our versioning policy.</p>
<p>[1] <a class="external" href="https://semver.org/">https://semver.org/</a></p> LTTng - Feature #1268 (New): Adopting a Vulnerability Disclosure Policy for our projectshttps://bugs.lttng.org/issues/12682020-05-22T19:27:49ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Some organization might require/appreciate such policy.</p>
<p>We could probably base our policy on <a class="external" href="https://disclose.io/">https://disclose.io/</a>, considering they have "terms" [1] with canada in mind.</p>
<p>[1] <a class="external" href="https://github.com/disclose/disclose/tree/master/terms">https://github.com/disclose/disclose/tree/master/terms</a></p>
<p>IANAL</p> LTTng-modules - Feature #1265 (New): Turn lttng-probes.c probe_list into a hash tablehttps://bugs.lttng.org/issues/12652020-05-06T17:14:59ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Turns O(n^2) trace systems registration (cost for n systems) into O(n). (O(1) per system)</p> LTTng-modules - Feature #1264 (New): NOHZ support for lib ring bufferhttps://bugs.lttng.org/issues/12642020-05-06T17:14:02ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>NOHZ infrastructure in the Linux kernel does not support notifiers chains, which does not let LTTng play nicely with low power consumption setups for flight recorder (overwrite mode) live traces. ne way to allow integration between NOHZ and LTTng would be to add support for such notifiers into NOHZ kernel infrastructure.</p>