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-tools - Feature #1391 (New): Add 'enable-events' as a special argument to lttng-toolshttps://bugs.lttng.org/issues/13912023-09-26T13:39:06ZMatthew Khouzammatthew.khouzam@ericsson.com
<p>I have observed users trying to enable events by running</p>
<pre>
lttng enable-events -a -u
</pre><br /> or<br /><pre>
lttng enable-events -a -k
</pre><br /> with the logic that they are enabling several events. Then they panic when there is an error message. As this is an understandable issue, maybe it would be worth giving a clearer message: "It looks like you are trying to run 'enable-event'" or something similar. LTTng-UST - Bug #1294 (New): add-context fails silently with perf_event_paranoid=4, no trace prod...https://bugs.lttng.org/issues/12942020-12-02T23:45:38ZJeff Trull
<p>Desired result:<br />A disallowed add-context (e.g. because of perf_event_paranoid) produces an error message and a non-zero exit code.</p>
<p>Actual result:<br />A disallowed add-context produces only a message in the system log, invisible to the normal user.<br />For example, when perf_event_paranoid forbids it you get a message of the form:</p>
<p><code>Error: UST app create channel context failed for app (pid: 76220) with ret -1024</code></p>
<p>But the only effects observable to the user are:</p>
<ol>
<li>no trace is produced, and</li>
<li>when you destroy the session there is a message like <code>Failed to perform a quiet rotation as part of the destruction of session "..."</code></li>
</ol>
<p>If other users are like me they will spend quite some time trying to figure out what is wrong in their code, setup etc. before figuring out what's wrong (or having someone on IRC identify it for them, as in my case).</p>
<p>This is Ubuntu 20.04.1, with lttng-ust 2.11.0</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 #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> LTTng-UST - Feature #1100 (New): Add (possibly symbolic) event whenever blocking occurs due to ex...https://bugs.lttng.org/issues/11002017-05-08T17:24:36ZRicardo Nabinger Sanchezrnsanchez@gmail.com
<p>When using <code>LTTNG_UST_BLOCKING_RETRY_TIMEOUT</code>, it is desirable to know when blocking occured. This way an analyst will stay informed of periods in the trace where precision of events had to be traded for completeness.</p>
<p>This has been discussed informally in the IRC channel:<br /><pre>
[09:08:06] rnsanchez such points could be of interest in my analysis :+)
[09:59:35] Compudj rnsanchez: no
[10:01:19] Compudj rnsanchez: but looking at event clusters in your trace will help
[10:01:36] rnsanchez Compudj: what about throwing a single/occasional event for a corresponding tid/pid that was ungraced due to excessive events?
[10:01:56] Compudj rnsanchez: with multi-session support, that would not be that easy
[10:02:04] Compudj we'd have to know which buffers are affected
[10:02:22] Compudj so we don't generate noise into other sessions
[10:02:36] rnsanchez I see
[10:02:37] rnsanchez sounds fair
[10:03:35] Compudj rnsanchez: if we add such info eventually, I'd be tempted to add a packet header field for that
[10:03:47] Compudj which could counts the "blocking" a buffer has had so far
[10:04:11] Compudj so we don't rely on events to relay information that is transport-level
[10:04:35] Compudj that would be doable (you may want to add a feature request on bugs.lttng.org)
[10:05:26] rnsanchez well that kind of info could be "rendered" into tools such as Trace Compass. it would be informative enough for the analyst to take a convolute period with a grain/spoon of salt
[10:05:57] rnsanchez Compudj: I can do that, sure
[10:06:04] Compudj rnsanchez: yes, and having those counters in the packet header would nicely match the spots where the situation occurs
[10:06:15] Compudj blocking always happen at sub-buffer (packet) boundary
[10:09:06] rnsanchez so it would act (briefly) as a relaxed clock? i.e., "between events En and En+1, we blocked, take that into account"
[10:09:24] rnsanchez (relaxed as in not actually probing clocks for a timestamp)
[10:10:43] Compudj yes, if we detect that the blocking counter increased between two consecutive packets, we can put a marker between timestamp end of the first packet and timestamp begin of the second packet saying that the source has been blocked during that time
[10:11:11] rnsanchez perfect
[10:12:19] Compudj you may want to paste this conversation into the bug tracker feature request, it will make it easier to remember the details when/if we get to implement it
[10:13:26] rnsanchez doing that as we speak
</pre></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 #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 #961 (New): Add additional criteria to disable-eventhttps://bugs.lttng.org/issues/9612015-10-22T19:42:43ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Add the necessary criteria to disable-event to procure a way to disable events based on filter string, loglevel etc.</p> LTTng-tools - Feature #960 (New): Add a -m /--matching argument to enable-eventhttps://bugs.lttng.org/issues/9602015-10-22T19:29:17ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>--matching would provide a way to reflect the behavior of disable-event which is a per field (name, filter, loglevel) event matching</p>
<p>By default enable-event would still try to enable a single event with static field check.</p>
<p>When in matching mode enable-event would iterate the current list of enabled events and enable events based on field matching (name, filter, loglevel) provided via arguments.</p> LTTng-UST - Feature #602 (New): Add session to metadata environmenthttps://bugs.lttng.org/issues/6022013-07-24T18:36:42ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>To aid in identifying the trace, we should add the session in the metadata (in the environment section)</p> LTTng-modules - Feature #601 (New): Add session to metadata environmenthttps://bugs.lttng.org/issues/6012013-07-24T17:26:51ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>To aid in identifying the trace, we should add the session in the metadata (in the environment section)</p> LTTng-UST - Feature #527 (New): Add git version information to project versionhttps://bugs.lttng.org/issues/5272013-05-10T12:54:46ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-UST - Feature #520 (New): Allow override of /var/run directoryhttps://bugs.lttng.org/issues/5202013-05-04T13:59:36ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Allow override of /var/run directory, as will as per-user $HOME/.lttng/ directory at configure time, and by environment variables. This should match a similar feature in lttng-tools.</p>