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 - 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> 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 - 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 #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-tools - Feature #555 (Confirmed): add-context --help lists perf fields even when the machin...https://bugs.lttng.org/issues/5552013-05-31T18:13:39ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>This was taken from a machine running 3.2.0-40-virtual:</p>
<pre>
$ lttng add-context --help
usage: lttng add-context -t TYPE [-k|-u] [OPTIONS]
[...]
Context:
-t, --type TYPE Context type. You can repeat that option on
the command line to specify multiple contexts at once.
(--kernel preempts --userspace)
TYPE can be one of the strings below:
pid, procname, prio, nice, vpid, tid, pthread_id,
vtid, ppid, vppid, hostname, perf:cpu-cycles,
perf:cycles, perf:stalled-cycles-frontend,
perf:idle-cycles-frontend,
perf:stalled-cycles-backend,
perf:idle-cycles-backend, perf:instructions,
perf:cache-references, perf:cache-misses,
perf:branch-instructions, perf:branches,
perf:branch-misses, perf:bus-cycles,
perf:L1-dcache-loads, perf:L1-dcache-load-misses,
perf:L1-dcache-stores,
perf:L1-dcache-store-misses,
perf:L1-dcache-prefetches,
perf:L1-dcache-prefetch-misses,
perf:L1-icache-loads, perf:L1-icache-load-misses,
perf:L1-icache-stores,
perf:L1-icache-store-misses,
perf:L1-icache-prefetches,
perf:L1-icache-prefetch-misses, perf:LLC-loads,
perf:LLC-load-misses, perf:LLC-stores,
perf:LLC-store-misses, perf:LLC-prefetches,
perf:LLC-prefetch-misses, perf:dTLB-loads,
perf:dTLB-load-misses, perf:dTLB-stores,
perf:dTLB-store-misses, perf:dTLB-prefetches,
perf:dTLB-prefetch-misses, perf:iTLB-loads,
perf:iTLB-load-misses, perf:branch-loads,
perf:branch-load-misses, perf:cpu-clock,
perf:task-clock, perf:page-fault, perf:faults,
perf:major-faults, perf:minor-faults,
perf:context-switches, perf:cs,
perf:cpu-migrations, perf:migrations,
perf:alignment-faults, perf:emulation-faults
Example:
[...]
$ dmesg | grep "generic register"
$
</pre>
<p>Trying to <code>add-context -t perf:*</code> on such a machine fails, of course.</p>
<p>It would be a simple yet useful enhancement to forgo listing perf context types when none are actually possible.</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-tools - Feature #286 (Confirmed): Add a --logfile option (or log through Syslog)https://bugs.lttng.org/issues/2862012-06-21T22:21:15ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>When we start lttng-sessiond in deamon mode, there is no way to get the verbose log.</p>
<p>having an option to log to a file and to syslog would be nice to debug deamon cases.</p>