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 - 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> 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 - 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> 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> LTTng - Feature #981 (New): Handle the flush of the last subbufferhttps://bugs.lttng.org/issues/9812015-11-27T23:17:13ZJulien Desfossezjdesfossez@efficios.com
<p>Currently, when doing lttng stop, we use the SWITCH_ACTIVE flag of the flush command to finalize the current subbuffer and prepare a new one, so when we do the destroy command, we always flush a subbuffer that contains only the headers (no data).</p>
<p>The reason for this is that we absolutely want to know the duration of the trace capture, so we can then reliably use the packet-intersect feature in the trace readers.</p>
<p>The only case where creating a new empty packet is required is when we recorded no new event since the last packet was completed and the stop command. Not creating a new packet on stop would then result in a trace that seems to have been recording up to the last event event though the trace was still active for some time after this event (but no events were generated).</p>
<p>The drawback of always creating a new packet on stop, is on architectures with big pages (ex: ppc with 64k pages) when running in tracefile rotation, because a big page of zeros can trigger the tracefile rotation more easily and overwrite useful data.</p>
<p>So we would need to create a new flush mode to only create a new packet if at the time we have no currently opened packet (the last packet has been closed and no new events have been recorded since so we don't have a current packet initialized).<br />In this particular case, we would create and immediately close a new packet to make sure we have the real duration of the session.</p>
<p>In addition, this would remove the timestamp of the destroy command from the trace, we would only have the timestamp of the stop command which is more accurate for the packet-intersect feature.</p> LTTng - Feature #211 (New): Environment varshttps://bugs.lttng.org/issues/2112012-04-12T16:44:18ZMatthew Khouzam
Hi, I think it would be an interesting items to put in the environment variables.
<ul>
<li>Session creation time. ( To be sure you're dealing with the right trace) </li>
<li>Session destruction time. </li>
<li>Cpuinfo ( to understand performance, if you're running a 386 or an i7, the latencies are different)</li>
<li>Amount of Ram ( could quickly explain swapping)</li>
<li>hw info </li>
<li>network info</li>
<li>hostname (oops tracing the wrong machine)</li>
</ul>