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-UST - Bug #1285 (Feedback): about close file failed for lttng-ust modulehttps://bugs.lttng.org/issues/12852020-10-10T09:52:42Zkun song
<p>Hi,all</p>
<p>I found some relative modification for lttng-ust.<br />commit<br />20d1999d42392063fd530d1f6c00b93c25d178d6<br />793d29c9367a58c2a368bc1ccb11b01c2d2bdac2<br />48a143c09cc97bf7a2ace811277e7d60b294b5f6<br />96a6162e1925d4bd1dfc6f4167d75f396c0dbe4c<br />283f4bec47781f7a39dde82d02e53add02155f9c<br />c1be081a2f016fb6dcaef1d471389ede3aa00103<br />5a4d96d170a38f29bf147b84e248a47d45ee7d8e<br />7d34f27dce903a88241e96787c1f900b6ea08245<br />ba8dcc8ca5b8b7bebed4e10b3dd4fcbc783d529d</p>
<p>Test step<br />LD_PRELOAD=lttng-ust-fork.so dpdk-devbind.py -s<br />When exec command,close file failed.</p>
<p>#1 0x00007f31b9705524 in __GI_abort () at abort.c:79</p>
<p>[**ALERT: The abort() might not be exactly invoked from the following function line.<br />If the trail function contains multiple abort() calls, then you should cross check by other means to get correct abort() call location.<br />This is due to the optimized compilation which hides the debug info for multiple abort() calls in a given function.<br />Refer TR HU16995 for more information]<br />#2 0x00007f31b970540f in _<em>assert_fail_base (fmt=0x7f31b9862ec8<br />"%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7f31b96bbcdd "0", file=0x7f31b96c4cd0 <del>Type <RET> for more, q to quit, c to continue without paging</del> "../../git/libringbuffer/shm.c", line=427, function=<optimized out>) at<br />assert.c:92<br />#3 0x00007f31b97127d2 in _GI</em>_assert_fail (assertion=assertion@entry =0x7f31b96bbcdd "0", file=file@entry=0x7f31b96c4cd0 "../../git/libringbuffer/shm.c", line=line@entry=427,<br />function=function@entry=0x7f31b96c4dc0 <_PRETTY_FUNCTION_.4744><br />"shmp_object_destroy") at assert.c:101<br />#4 0x00007f31b96b3f1d in shmp_object_destroy (obj=obj@entry=0x7f31b401 1740, consumer=consumer@entry=0) at ../../git/libringbuffer/shm.c:427<br />#5 0x00007f31b96b4d4f in shm_object_table_destroy (table=0x7f31b4011730, consumer=consumer@entry=0) at<br />../../git/libringbuffer/shm.c:451<br />#6 0x00007f31b96b034d in channel_free (consumer=0, handle=0x7f31b4012f10, chan=0x7f31b4011170) at<br />../../git/libringbuffer/ring_buffer_frontend.c:926<br /><a class="issue tracker-1 status-5 priority-5 priority-high2 closed" title="Bug: Double PID registering and unregistering race (Resolved)" href="https://bugs.lttng.org/issues/7">#7</a> channel_release (consumer=0, handle=0x7f31b4012f10,<br />chan=0x7f31b4011170) at<br />../../git/libringbuffer/ring_buffer_frontend.c:1129<br />#8 channel_destroy (chan=0x7f31b4011170, handle=0x7f31b4012f10,<br />consumer=consumer@entry=0) at</p>
<p>../../git/libringbuffer/ring_buffer_frontend.c:1161</p> LTTng - Bug #1208 (Feedback): 2.11 relayd in live mode attach window changedhttps://bugs.lttng.org/issues/12082019-11-06T19:59:35ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Previously on a lttng 2.10 relayd/tools the following sequence is acceptable and result in a hooked babeltrace:</p>
<pre>
lttng create
lttng enable-event -u -a
babeltrace -i lttng-live net://localhost
babeltrace -i lttng-live net://localhost/the_session_path
lttng start
</pre>
<p>On lttng 2.11, the same sequence leave babeltrace unable to hook itself before a "lttng start" is issued.</p>
<p>Nothing describe the guarantee that we expose on that side but we do have to ask ourselves if this sequence of action is valid or not.</p>
<p>A scenario where the user want to make sure to get the event ASAP on babeltrace side might want to hook itself to the session before any event can be recorded.</p>
<p>This was found using the lttng-ivc project. The test code was adapted to a functioning sequence but this should require more discussion overall. This is in no way a major concern.</p>
<p>Cheers</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-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-tools - Bug #797 (Feedback): Add more test for epoll in configurehttps://bugs.lttng.org/issues/7972014-05-21T19:26:05ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>I was trying to compile lttng-tools on centos 5 (yes I know too old), but configure did not complain.</p>
<p>We should test for the presence of these and fail configure or add a compat layer.</p>
<p>In file included from compat-epoll.c:33:<br />poll.h:72: error: 'EPOLLRDHUP' undeclared here (not in a function)<br />poll.h:74: error: 'EPOLL_CLOEXEC' undeclared here (not in a function)<br />compat-epoll.c: In function 'compat_epoll_create':<br />compat-epoll.c:84: warning: implicit declaration of function 'epoll_create1'</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>