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> 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-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-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> LTTng-tools - Feature #1197 (New): Use renameat2() to atomically exchange metadata on metadata re...https://bugs.lttng.org/issues/11972019-09-23T16:56:22ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>When using shm-path, a use-case is to expect the sessiond or the system to crash at any point during tracing.</p>
<p>If such a crash occurs while regenerating the metadata, lttng-crash may find a truncated file.</p>
<p>It would be nice if we could generate the new metadata in a ".metadata.new" file while keeping the old file around, and then exchange both files using renameat2().</p>
<p>However, renameat2() appeared in kernel 3.15, so we would have to figure out a fallback.</p> LTTng-tools - Feature #1066 (New): Add option for lttng-destroy to delete the trace folderhttps://bugs.lttng.org/issues/10662016-10-07T02:45:07ZFrancis Deslauriersfrancis.deslauriers@efficios.com
<p>This would be useful when testing session, channel and event configurations.<br />When testing configuration the trace itself has no value and can be deleted at the end of the session.</p>
<p>The option could be '-r' or '--remove'<br />e.g. lttng destroy -r</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-tools - Feature #821 (New): trace session name in the metadatahttps://bugs.lttng.org/issues/8212014-07-22T20:36:26ZJulien Desfossezjdesfossez@efficios.com
<p>Would it be possible to add the session name into the trace metadata so that we can find it without relying on the trace directory (which can be quite complex) ?</p> LTTng-tools - Feature #750 (Confirmed): lttng add-context --channel should accept a list of channelshttps://bugs.lttng.org/issues/7502014-03-07T17:14:31ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>It would be nice if the <code>--channel</code> option of the <code>lttng add-context</code> command accepted a list of channel names (e.g. comma-separated with no intervening spaces).</p> LTTng-UST - Feature #717 (New): Better validation of tracepoint provider headers?https://bugs.lttng.org/issues/7172014-01-15T17:35:27ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>I fooled around to try and break the LTTng tracepoint provider preparation process at the level of the event field names. Turns out the literals supplied to the <code>ctf_*</code> macros as arguments for <code>TP_FIELDS</code> are pretty robust. Maybe too robust.</p>
<p>If you supply a non-identifier (see ISO/IEC 9899:TC2 (9899:1999) at 6.4.2 and Annex D) such as for instance "<code>named name</code>" or "<code>.name</code>", the tracepoint provider header compiles, links and packages into an <code>.so</code> without a hitch. The instrumented application likewise. Tracing also works flawlessly, producing a trace on disk. But when <code>babeltrace</code> tries to read it, it complains and gives up, with messages like:</p>
<pre>
[error] at line 110: token "name": syntax error, unexpected IDENTIFIER, expecting SEMICOLON or COMMA
[...]
</pre>
<p>(for "<code>named name</code>") or</p>
<pre>
[error] at line 110: token ".": syntax error, unexpected DOT, expecting SEMICOLON or COMMA
[...]
</pre>
<p>(for "<code>.name</code>")</p>
<p>There isn't much that can be done to prevent this. I would recommend merely amending the tracepoint provider samples slightly, like this:</p>
<pre>
/*
* The ctf_string macro takes a C string and writes it into a field
* named "message" (any C identifier will do for the field name)
*/
ctf_string(message, text)
</pre>