LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912023-06-01T18:48:58ZLTTng bugs repository
Redmine LTTng-tools - Bug #1379 (New): Document behavior of live mode with per-pid UST buffershttps://bugs.lttng.org/issues/13792023-06-01T18:48:58ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>There is a design limitation of per-pid UST buffers when used in live mode which should be documented.</p>
<p>Basically, because the per-pid buffers are reclaimed soon after the application exits, it may cause the events traced by a short-lived application to never appear in the output of a live trace when per-pid buffers are used.</p>
<p>This is caused by the fact that the live client periodically checks for new buffers, but there is no inherent reference kept on the streams before they disappear.</p>
<p>This means that the information will be available in the disk output of the trace, but it will be missing from the live mode output.</p>
<p>This could eventually be mitigated by keeping references to the streams received by the relay daemon which are of interest to a live client until they are referenced by the live client.</p> LTTng-tools - Bug #1378 (New): Document behavior of snapshot mode with per-pid UST buffershttps://bugs.lttng.org/issues/13782023-06-01T18:01:12ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We should document a design limitation of the per-pid UST buffers which can lead to unexpected results when used with the "snapshot" feature.</p>
<p>Basically, because the per-pid buffers lifetime is bound by the application using them (and the consumer daemon extracting data from them), they are freed almost immediately after the traced application exits. However, in a scenario where we are interested in capturing a snapshot of the content of flight recorder buffers soon after application exits (e.g. caused by a crash), those buffers are not available anymore a few milliseconds after the application exits.</p>
<p>We should document this design limitation, and eventually think about improvements (feature request ?) to allow a configurable delay after application exit during which the consumer daemon could keep references on the buffers so they are available for snapshot.</p> LTTng-tools - Bug #1340 (New): Document behavior of per-uid UST buffers with respect to asynchron...https://bugs.lttng.org/issues/13402021-12-07T20:22:28ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We should document a known design limitation of the per-uid UST buffers:</p>
<p>When using lttng-ust with per-uid buffers, there is a known design limitation<br />regarding process terminated by non-handled kill signals: if this occurs while<br />the buffer is being written to (between reserve and commit), it will cause the<br />rest of the per-cpu buffer to be unreadable. This applies to all events<br />recorded by all applications of the same user id for that particular CPU.<br />Recovering from this involves destroying and re-creating the tracing session.</p>
<p>If this kind of scenario is likely for you, you might want to consider using per-<br />pid buffers (lttng enable-channel -u --buffers-pid), which do not suffer from<br />this design limitation. The downside of per-pid buffers is that it allocates<br />more memory on your system for buffering, and adds extra overhead when<br />used with processes that have a short life-time.</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 - Bug #1295 (New): Copy-pasto in bt_value_map_borrow_entry_value dochttps://bugs.lttng.org/issues/12952020-12-15T05:54:56ZSimon Marchisimon.marchi@polymtl.ca
<p>Here:</p>
<p><a class="external" href="https://babeltrace.org/docs/v2.0/libbabeltrace2/group__api-val.html#gaf3e38ff6931760cf4dc56ca0c8354f02">https://babeltrace.org/docs/v2.0/libbabeltrace2/group__api-val.html#gaf3e38ff6931760cf4dc56ca0c8354f02</a></p>
<p>It says <code>value is an array value (bt_value_is_array() returns BT_TRUE).</code>. Should be map, not array.</p> Babeltrace - Bug #1289 (New): docs: document that the "notext" flag is required to build out of t...https://bugs.lttng.org/issues/12892020-11-04T22:06:23ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>This is related to the gerrit change <a href="https://review.lttng.org/c/babeltrace/+/4228" class="external">4228</a></p>
<p>When building an out-of-tree plug-in, users of LLVM ld (freeBSD, but also maybe macOS?) must ensure they pass the 'notext' flag.<br />See the discussion on the gerrit change for more context.</p>
<p>This should probably be documented under <a href="https://github.com/efficios/babeltrace/blob/43c59509042845f8d42c3e99ec74d45fa2dc0908/doc/api/libbabeltrace2/dox/guides.dox#L101" class="external">Compile and link a Babeltrace 2 shared object plugin of guides.dox</a></p> LTTng-UST - Bug #1203 (New): Improve documentation of lttng-ust with daemonshttps://bugs.lttng.org/issues/12032019-10-07T15:51:26ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>The lttng-ust(3) man page should be clarified regarding the scenarios where the liblttng-ust-fork.so wrapper is needed.</p>
<p>It should document that it is needed in scenarios where applications using fork(2), clone(2) (with CLONE_VM flag cleared), BSD's rfork(2), daemon(3), without <strong>immediately</strong> following those by an exec(3) family call. This includes scenarios where close(2) is used to close file descriptors before invoking exec(3), even though close(2) is listed as an async-signal-safe function.</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-tools - Bug #1158 (New): lttng-create(1) man page: it is not documented that --shm-path onl...https://bugs.lttng.org/issues/11582018-04-20T19:15:34ZPhilippe Proulxeeppeliteloop@gmail.com
<p>The <code>--shm-path</code> option of <code>lttng-create(1)</code> only applies to the user space domain. As of this date, <code>lttng-crash(1)</code> is only useful to recover user space traces. This is not documented.</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 - Bug #752 (In Progress): Output paths need better handling than truncationhttps://bugs.lttng.org/issues/7522014-03-07T21:33:50ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
For instance, in the aftermath of <code>lttng-tools/src/bin/lttng-sessiond/cmd.c:record_ust_snapshot</code>, the <code>msg.u.snapshot_channel.pathname</code> is limited to PATH_MAX (typically 4096) but is built with <code>"%s/%s-%s-%" PRIu64 "%s"</code>, where the successive arguments are (discounting the closing nulls):
<ul>
<li><code>output->consumer->dst.trace_path</code> PATH_MAX - 1 (no trailing /)</li>
<li>/ 1</li>
<li><code>output->name</code> NAME_MAX - 1</li>
<li>- 1</li>
<li><code>output->datetime</code> 15</li>
<li>- 1</li>
<li><code>output->nb_snapshot</code> 20 digits (unsigned 64-bit integer)</li>
<li><code>session_path</code> PATH_MAX - 1 (including leading and trailing /)</li>
</ul>
<p>The worst-case <code>session_path</code> part is <code>'/ust/pid/<proc>-<vpid>-<datetime>/'</code> so it's actually limited to 12+15+5+15 = 47 characters (<code>/proc/PID/status.name</code> is truncated to 15 characters, and VPID is unsigned 16-bit for 5 characters) (closing null excluded). So one solution would be to limit the <code>consumer->dst.trace_path</code> to PATH_MAX - (NAME_MAX - 1 + 15 + 20 + 47 + 3) - 1 (for the null). However, if we want the path+filetitles of the channel files to fit in PATH_MAX, we need to chop another NAME_MAX off (and also limit channel names to NAME_MAX - (1 + 5 + 1 + 10 + 1) [underscore, 16-bit unsigned CPU ID, underscore, 32-bit unsigned chunk number, null] so they fit).</p>
<p>Truncation remains nevertheless possible, and would wreak havoc with the trace output tree. <code>Babeltrace</code> and the user count on proper folder and file tree structure to manage their traces. The code needs to detect instances of truncation and report them as errors.</p>
<p>As an aside, the snapshot output name should be limited to MAX_PATH - (1+10) because it gets suffixed with a hyphen and an unsigned 32-bit integer (the output set sequential ID).</p>