LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912023-10-10T15:23:31ZLTTng bugs repository
Redmine 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> 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> 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 - 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-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> LTTng-modules - Feature #1263 (New): Re-integrate sample modules from libringbuffer into lttng-mo...https://bugs.lttng.org/issues/12632020-05-06T17:13:20ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Re-integrate sample modules from libringbuffer into lttng-modules. Those modules can be used as example of how to use libringbuffer in other contexts than LTTng, and are useful to perform benchmarks of the ringbuffer library. See: <a class="external" href="https://github.com/compudj/linux-libringbuffer/tree/tip-current-ringbuffer-0.240">https://github.com/compudj/linux-libringbuffer/tree/tip-current-ringbuffer-0.240</a></p> Babeltrace - Bug #1234 (Feedback): src.text.dmesg: some kernel ring buffer lines can be wrongly s...https://bugs.lttng.org/issues/12342020-02-17T21:54:00ZPhilippe Proulxeeppeliteloop@gmail.com
<p>The lines of the <code>dmesg</code> command start with a time. The lines are supposed to be in order of time, but some of them can be at the wrong place.</p>
<p><code>flt.utils.muxer</code> does not like this and complains that event messages are not sorted by their default clock snapshot value.</p>
<p>It is, in fact, a <code>src.text.dmesg</code> bug because a message iterator must emit messages in order of time.</p>
<p>If the input is a file, one solution would be to sort the lines first (if not too large), and then emit the messages in this order.</p>
<p>We could also, in all scenarios, skip the lines with a time that is before the last event message's time and warn accordingly.</p> Babeltrace - Bug #1223 (Feedback): Check for cmp and diff in configurehttps://bugs.lttng.org/issues/12232020-02-17T21:03:26ZSimon Marchisimon.marchi@polymtl.ca
<p>Seen somewhere in the configure output of babeltrace on a fresh centos 8 container:</p>
<pre>
checking for a working dd... ./configure: line 9826: cmp: command not found
checking if gcc supports -fno-rtti -fno-exceptions... ./configure: line 11790: diff: command not found
</pre>
<p>The configure keeps going, I think the consequence may simply be that the results of these checks are inaccurate.</p>
<p>For correctness, if these tools (cmd and diff) are used, there should be something that checks that they exist before using them.</p> LTTng-tools - Bug #1159 (Feedback): Missing documentation: before Linux 4.17, suspending the syst...https://bugs.lttng.org/issues/11592018-04-20T19:22:26ZPhilippe Proulxeeppeliteloop@gmail.com
<p>From LWN:</p>
<blockquote>
<p>The CLOCK_MONOTONIC and CLOCK_BOOTTIME clocks used to differ only in that the latter is fast-forwarded after a suspend-and-resume cycle. As of 4.17, CLOCK_MONOTONIC is also moved forward to reflect the time that the system spent suspended. As a result, the two timers are now identical and have been unified within the kernel. Among other things, that change eliminates a potentially surprising behavior wherein the offset between the monotonic and realtime clocks would change after a resume. Thomas Gleixner noted: "There might be side effects in applications, which rely on the (unfortunately) well documented behaviour of the MONOTONIC clock, but the downsides of the existing behaviour are probably worse.</p>
</blockquote>
<p>We should document that LTTng can produce incorrect traces when the target system is suspended while tracing is active if the system runs Linux 4.16 or less.</p>
<p>Mathieu Desnoyers suggested that we put this in <code>lttng-regenerate(1)</code>'s man page. Is this the appropriate location? Should the warning exist in all command man pages (as a common limitation at the end of the page)? <code>lttng-create(1)</code>'s man page could also be an appropriate location.</p> LTTng - Bug #1060 (Confirmed): Document the extra reading subbuffer always allocatedhttps://bugs.lttng.org/issues/10602016-08-30T14:04:00ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>On channel creation a user might only consider the size of the passed argument instead we should either warn or document that there is always an extra sub buffer allocated for reading purpose.</p>
<p>See lib_ring_buffer_backend_allocate on lttng-modules.</p>
<p>This also apply to userspace.</p> LTTng-modules - Feature #999 (New): Support mmap for metadata channelhttps://bugs.lttng.org/issues/9992016-03-04T16:36:25ZJulien Desfossezjdesfossez@efficios.com
<p>Currently it is impossible to configure the metadata channel to work with mmap.</p>
<p>We noticed that on PPC64 BE with a 64-bit kernel and a 32-bit user-space (apparently the default setup for various distributions), we cannot record a kernel trace because they don't implement the splice compat syscall.</p>
<p>The LTTng command line does not complain if we enable manually the metadata channel for mmap, but it is still trying to use splice and fails in this setup.</p> LTTng - Feature #990 (Confirmed): Additional make check targetshttps://bugs.lttng.org/issues/9902016-01-19T20:23:31ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>We might want to add more make check targets to ease testing both manually and via ci.</p>
<p>E.g.<br />make check_verbose<br />make check_archive<br />make check_root<br />etc.</p> LTTng-modules - Feature #962 (New): add x86 exceptions.h and irq_vectors.h instrumentation (and m...https://bugs.lttng.org/issues/9622015-10-22T19:47:19ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-modules - Feature #336 (New): Support splice() for partial pageshttps://bugs.lttng.org/issues/3362012-09-13T19:36:42ZDavid Goulet
<p>Network streaming does NOT send the padded zeros over the network.</p>
<p>So, to extract data, we only use the real size of the subbuffer (without padding). However, the splice() actor of lttng-modules does not handle passing a partial page size to it returning EINVAL.</p>
<p>Once done, the support MUST be added to lttng-tools.</p>