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-tools - Bug #1256 (New): Check babeltrace1 stderr output in testshttps://bugs.lttng.org/issues/12562020-04-08T19:23:18ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Currently, babeltrace1 stderr's output contains warnings which are not checked by the tests. Those do not fail the overall babeltrace execution, but end up being unexpected regressions when they appear between releases.</p>
<p>We could modify all babeltrace invocations to add a helper which saves the stderr output, and check that it is empty after babeltrace has completed execution. If non-empty, a test error would be reported.</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 #1211 (New): Can't quit lttng-sessiond with ctrl-c when built with --disable-epollhttps://bugs.lttng.org/issues/12112019-11-28T21:59:44ZSimon Marchisimon.marchi@polymtl.ca
<p>Step 1: configure lttng-tools with <code>./configure --disable-epoll</code><br />Step 2: launch lttng-sessiond<br />Step 3: try to stop it with ctrl-c</p>
<p>It should quit, but it doesn't quit.</p>
<p>My thorough investigation has shown that the "client management" thread stays in an infinite loop in compat_poll_wait.</p> LTTng-tools - Bug #1072 (New): configure does not check for needed Libxml2 symbolshttps://bugs.lttng.org/issues/10722016-11-01T09:09:00ZPhilippe Proulxeeppeliteloop@gmail.com
<p>LTTng-tools's <code>configure</code> script checks for the existence and version of Libxml2 with pkg-config, but it does not check for the exact needed symbols. Libxml2 has a lot of <code>--with-</code> configuration options, some of which can disable modules that LTTng-tools needs.</p>
<p>I suggest that we check one selected symbol per module. This should ensure that at least the module exists, which should guarantee that the other symbols are available too.</p>
<p>It looks like the following Libxml2 configuration options enable the needed modules:</p>
<pre>
--with-minimum --with-sax1 --with-tree --with-writer --with-schemas
</pre>
<ul>
<li><code>--with-minimum</code> simply "resets" the enabled modules to none.</li>
<li><code>--with-sax1</code> is needed for basic XML parsing (load).</li>
<li><code>--with-tree</code> is needed for querying an XML document as a tree (load).</li>
<li><code>--with-writer</code> is needed for writing XML (save, MI).</li>
<li><code>--with-schemas</code> is needed for XML validation (load).</li>
</ul>
<p>All those options are available in the Libxml2 2.7.6 release (minimum required version by LTTng-tools).</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 - 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 - Bug #822 (Confirmed): bash-completion sometimes completes too muchhttps://bugs.lttng.org/issues/8222014-07-28T18:04:17ZSimon Marchisimon.marchi@polymtl.ca
<p>I am not sure how to word it, but here is an example. I have a single session, named "auto-20140728-134322".</p>
<p>$ lttng des<tab> => $ lttng destroy</p>
<p>That's good, now let's press tab again:</p>
<p>$ lttng destroy <tab> => $ lttng destroy auto-20140728-134322</p>
<p>That's good, now let's press tab again:</p>
<p>$ lttng destroy auto-20140728-134322 <tab> => $ lttng destroy auto-20140728-134322 auto-20140728-134322</p>
<p>Oops, we can go like that for a long time. Every <tab> press adds a "auto-20140728-134322". It should detect that we already gave a positional argument. Since the command takes only one positional argument, subsequent <tab> presses should do nothing.</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> LTTng-tools - Feature #270 (Confirmed): Be able to choose session by number in lttng list commandhttps://bugs.lttng.org/issues/2702012-06-18T18:31:05ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>When we list the session with lttng list we get a list prefixed by number</p>
<blockquote>
<p>Available tracing sessions:<br />1) test (/home/scientist/lttng-traces/test-20120618-142554) [inactive]</p>
</blockquote>
<p>It seems natural after that to use this number when we want to have the detail of a session</p>
<blockquote>
<p>lttng list 1</p>
</blockquote>
<p>instead of doing lttng list test</p>
<p>(Its particularly painfull with the auto generated names.</p> LTTng-tools - Feature #77 (Confirmed): Create developper documentation for the LTTng "control" APIhttps://bugs.lttng.org/issues/772012-02-20T17:56:05ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>Anyone seeing that and there is no comments indicating otherwise, please contribute!!! :)</p>