LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912021-06-07T15:17:28ZLTTng bugs repository
Redmine LTTng-tools - Bug #1318 (New): lttng-tools configured with --with-consumerd32-libdir --with-consu...https://bugs.lttng.org/issues/13182021-06-07T15:17:28ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>The lttng-tools project is configured as such:</p>
<pre>
./configure --with-consumerd32-libdir=/usr/local/lib32 --with-consumerd32-bin=/usr/local/lib32/lttng/libexec/lttng-consumerd
</pre>
<p>Config.h does include definition for consumerd32 bit<br /><pre>
/* Location of the 32-bit consumerd executable. */
#define CONFIG_CONSUMERD32_BIN "/usr/local/lib32/lttng/libexec/lttng-consumerd"
/* Search for consumerd 32-bit libraries in this location. */
#define CONFIG_CONSUMERD32_LIBDIR "/usr/local/lib32"
</pre></p>
<p>On start the sessiond ignore those paths:</p>
<pre>
DEBUG1 - 14:57:13.370775164 [113567/113567]: consumerd32 path: /home/vagrant/.lttng/ustconsumerd32
DEBUG1 - 14:57:13.370793022 [113567/113567]: consumerd32 bin path: Unknown
DEBUG1 - 14:57:13.370825408 [113567/113567]: consumerd32 lib dir: Unknown
</pre>
<p>The code does not use CONFIG_CONSUMERD32_BIN anywhere.</p>
<p>Commit e6142f2e647e83238b1e399b1264e8adb05409f9 seems to have removed the code that used CONFIG_CONSUMERD32_BIN without providing an equivalent.</p>
<pre>
commit e6142f2e647e83238b1e399b1264e8adb05409f9
Author: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Date: Thu Nov 9 17:46:54 2017 -0500
centralize sessiond config option handling
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
</pre>
<pre>
-static const char *consumerd32_bin = CONFIG_CONSUMERD32_BIN;
-static const char *consumerd64_bin = CONFIG_CONSUMERD64_BIN;
-static const char *consumerd32_libdir = CONFIG_CONSUMERD32_LIBDIR;
-static const char *consumerd64_libdir = CONFIG_CONSUMERD64_LIBDIR;
</pre>
<p>Using the command line works fine:<br /><pre>
lttng-sessiond -vvv --verbose-consumer --consumerd32-libdir=/usr/local/lib32 --consumerd32-path=/usr/local/lib32/lttng/libexec/lttng-consumerd
</pre></p>
<p>Not sure if we want to use the path provided by configure or simply change the documentation to indicate that the paths must be passed either via the env or on the command line.</p> LTTng - Bug #1305 (New): Kernel test hang https://bugs.lttng.org/issues/13052021-04-13T19:54:29ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>The stable 2.12 kernel test for snapshot hang and timeout:</p>
<pre>
# Test local kernel snapshots with small discard buffers
ok 33 - Create session wIlYlgBxrDYiYhCQ in no-output mode
ok 34 - Enable small discard channel snapchan for session wIlYlgBxrDYiYhCQ
ok 35 - Enable kernel syscall -a for session wIlYlgBxrDYiYhCQ on channel snapchan
ok 36 - Start tracing for session wIlYlgBxrDYiYhCQ
ok 37 - Added snapshot output file:///tmp/tmp.YQ8oTaPXHl
ok 38 - Snapshot recorded
# First line (1st snapshot): [19:42:21.079000064] (+?.?????????) linaro-server syscall_exit_clone: { cpu_id = 3 }, { ret = 0 }
Marking unfinished test run as failed
case: 2_kernel-tests
case_id: 1930082
commit_id: 352aca7ac22367a79ad817c23753317d7a8ec281
definition: lava
duration: 9939.86
result: fail
uuid: 37271_1.4.2.4.9
lava-test-shell timed out after 10651 seconds
end: 3.1 lava-test-shell (duration 02:57:31) [common]
case: lava-test-shell
case_id: 1930083
definition: lava
duration: 10651.01
extra: ...
level: 3.1
namespace: common
result: fail
lava-test-retry failed: 1 of 1 attempts. 'lava-test-shell timed out after 10651 seconds'
</pre>
<p>The job name : vm_tests_klinux-4.9.y_lstable-2.12</p>
<p>See attached file for complete job logs.</p> LTTng-tools - Bug #1219 (New): regression/tools/clear intermitent failure on powerpchttps://bugs.lttng.org/issues/12192020-02-06T20:31:49ZMichael Jeansonmjeanson@efficios.com
<p>This sometimes fail on the 2.12 branch on powerpc, might not be related to the architecture, just the fact that our ppc builders are slow.</p>
<pre>
15:14:14 # Waiting for live viewers on url: net://localhost
15:14:14 ok 955 - Waiting for live viewers on url: net://localhost
15:14:14 PASS: tools/clear/test_ust 955 - Waiting for live viewers on url: net://localhost
15:14:14 02-05 15:04:36.302 27915 27915 E PLUGIN/CTF/MSG-ITER create_msg_stream_end@msg-iter.c:2520 [lttng-live] Cannot create stream end message because stream is NULL: msg-it-addr=0x1b3d820
15:14:14 02-05 15:04:36.302 27915 27915 E PLUGIN/SRC.CTF.LTTNG-LIVE lttng_live_iterator_close_stream@lttng-live.c:855 [lttng-live] Error getting the next message from CTF message iterator
15:14:14 02-05 15:04:36.302 27915 27915 W LIB/MSG-ITER bt_self_component_port_input_message_iterator_next@iterator.c:920 Component input port message iterator's "next" method failed: iter-addr=0x1b3b680, iter-upstream-comp-name="lttng-live", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE, iter-upstream-comp-class-name="lttng-live", iter-upstream-comp-class-partial-descr="Connect to an LTTng relay daemon", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
15:14:14 02-05 15:04:36.302 27915 27915 E PLUGIN/FLT.UTILS.MUXER muxer_upstream_msg_iter_next@muxer.c:444 [muxer] Error or unsupported status code: status-code=-1
15:14:14 02-05 15:04:36.302 27915 27915 E PLUGIN/FLT.UTILS.MUXER validate_muxer_upstream_msg_iters@muxer.c:975 [muxer] Cannot validate muxer's upstream message iterator wrapper: muxer-msg-iter-addr=0x1b36ec0, muxer-upstream-msg-iter-wrap-addr=0x1b3b410
15:14:14 02-05 15:04:36.302 27915 27915 E PLUGIN/FLT.UTILS.MUXER muxer_msg_iter_next@muxer.c:1371 [muxer] Cannot get next message: comp-addr=0x1b3aae0, muxer-comp-addr=0x1b3aa20, muxer-msg-iter-addr=0x1b36ec0, msg-iter-addr=0x1b3b510, status=ERROR
15:14:14 02-05 15:04:36.302 27915 27915 W LIB/MSG-ITER bt_self_component_port_input_message_iterator_next@iterator.c:920 Component input port message iterator's "next" method failed: iter-addr=0x1b3b510, iter-upstream-comp-name="muxer", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=FILTER, iter-upstream-comp-class-name="muxer", iter-upstream-comp-class-partial-descr="Sort messages from multiple inpu", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
15:14:14 02-05 15:04:36.302 27915 27915 W LIB/GRAPH consume_graph_sink@graph.c:600 Component's "consume" method failed: status=ERROR, comp-addr=0x1b3add0, comp-name="pretty", comp-log-level=WARNING, comp-class-type=SINK, comp-class-name="pretty", comp-class-partial-descr="Pretty-print messages (`text` fo", comp-class-is-frozen=1, comp-class-so-handle-addr=0x1b45cc0, comp-class-so-handle-path="/home/jenkins/workspace/lttng-tools_stable-2.12_slesbuild/arch/sles12sp2/babeltrace_version/stable-2.0/build/std/conf/std/liburcu_version/stable-0.11/test_type/base/deps/build/lib/babeltrace2/plugins/babeltrace-plugin-text.so", comp-input-port-count=1, comp-output-port-count=0
15:14:14 02-05 15:04:36.302 27915 27915 E CLI cmd_run@babeltrace2.c:2590 Graph failed to complete successfully
15:14:14
15:14:14 ERROR: [Babeltrace CLI] (babeltrace2.c:2590)
15:14:14 Graph failed to complete successfully
15:14:14 CAUSED BY [libbabeltrace2] (graph.c:600)
15:14:14 Component's "consume" method failed: status=ERROR, comp-addr=0x1b3add0,
15:14:14 comp-name="pretty", comp-log-level=WARNING, comp-class-type=SINK,
15:14:14 comp-class-name="pretty", comp-class-partial-descr="Pretty-print messages
15:14:14 (`text` fo", comp-class-is-frozen=1, comp-class-so-handle-addr=0x1b45cc0,
15:14:14 comp-class-so-handle-path="/home/jenkins/workspace/lttng-tools_stable-2.12_slesbuild/arch/sles12sp2/babeltrace_version/stable-2.0/build/std/conf/std/liburcu_version/stable-0.11/test_type/base/deps/build/lib/babeltrace2/plugins/babeltrace-plugin-text.so",
15:14:14 comp-input-port-count=1, comp-output-port-count=0
15:14:14 CAUSED BY [libbabeltrace2] (iterator.c:920)
15:14:14 Component input port message iterator's "next" method failed:
15:14:14 iter-addr=0x1b3b510, iter-upstream-comp-name="muxer",
15:14:14 iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=FILTER,
15:14:14 iter-upstream-comp-class-name="muxer",
15:14:14 iter-upstream-comp-class-partial-descr="Sort messages from multiple inpu",
15:14:14 iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
15:14:14 CAUSED BY [libbabeltrace2] (iterator.c:920)
15:14:14 Component input port message iterator's "next" method failed:
15:14:14 iter-addr=0x1b3b680, iter-upstream-comp-name="lttng-live",
15:14:14 iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE,
15:14:14 iter-upstream-comp-class-name="lttng-live",
15:14:14 iter-upstream-comp-class-partial-descr="Connect to an LTTng relay daemon",
15:14:14 iter-upstream-port-type=OUTPUT, iter-upstream-port-name="out", status=ERROR
15:14:14 CAUSED BY [lttng-live: 'source.ctf.lttng-live'] (lttng-live.c:855)
15:14:14 Error getting the next message from CTF message iterator
15:14:14 CAUSED BY [lttng-live: 'source.ctf.lttng-live'] (msg-iter.c:2520)
15:14:14 Cannot create stream end message because stream is NULL: msg-it-addr=0x1b3d820
15:14:14 ok 956 - Clear session RCZWkxL3yzk8ayBb
15:14:14 PASS: tools/clear/test_ust 956 - Clear session RCZWkxL3yzk8ayBb
15:14:14 ok 957 - Stop lttng tracing for session RCZWkxL3yzk8ayBb
15:14:14 PASS: tools/clear/test_ust 957 - Stop lttng tracing for session RCZWkxL3yzk8ayBb
15:14:14 ok 958 - Destroy session RCZWkxL3yzk8ayBb
15:14:14 PASS: tools/clear/test_ust 958 - Destroy session RCZWkxL3yzk8ayBb
15:14:14 # Wait for viewer to exit
15:14:14 not ok 959 - Babeltrace succeeds
15:14:14 FAIL: tools/clear/test_ust 959 - Babeltrace succeeds
15:14:14 # Failed test 'Babeltrace succeeds'
15:14:14 # in ./tools/clear/test_ust:test_ust_streaming_live_viewer() at line 292.
</pre> LTTng-tools - Feature #1180 (New): SDT tracing does not work when the probes are compiled with se...https://bugs.lttng.org/issues/11802019-03-27T15:41:21ZNaser Ez
<p>Tracing SDT probes does not work when the probes are compiled with semaphores.</p>
<p>For example, when we have a probe like:</p>
<pre>
Provider: nginx
Name: http__subrequest__start
Location: 0x0000000000429e9c, Base: 0x0000000000473810, Semaphore: 0x00000000006920ba
Arguments: 8@%rbx__
</pre>
<p>then running the following command:<br /><pre>
lttng enable-event -k nginx:http__subrequest__start --userspace-probe=sdt:/usr/local/nginx/sbin/nginx:nginx:http__subrequest__start
</pre></p>
<p>will generate this error:<br /><pre>
Error: Event nginx:http__subrequest__start: Invalid userspace probe location (channel channel0, session auto-20190327-105118)
</pre></p> LTTng - Bug #1177 (Confirmed): Document --pidfile of lttng-sessiond executablehttps://bugs.lttng.org/issues/11772019-03-05T19:00:20ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>All is in title.</p>
<p>For anyone that receive all issue created, we had a db problem on upgrade to redmine 4.0 hence why I created it again.</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 - Feature #1137 (Confirmed): Version handshake for lttng-consumerd and lttng-sessiondhttps://bugs.lttng.org/issues/11372017-11-15T23:37:32ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
Scenario:
<ul>
<li>User installed both a 32bit and 64 bit version of lttng-tools 2.X.</li>
<li>User uses in script lttng-session --consumerd32-path= --consumerd64-path=</li>
<li>User update the 64bit version to lttng-tools 2.(X+1) without upgrading</li>
<li>User still uses it's script but with the lttng-sessiond bin from lttng-tools 2.(X+1)</li>
</ul>
<p>Currently the consumerd and sessiond do not exchange version information hence we end up with undefined behaviour.</p>
<p>The version numbering might be coupled with the version of lttng but it is most probably wiser to use a separate versioning.</p> LTTng-tools - Feature #1133 (New): Metadata regeneration does not have to be "destructive"https://bugs.lttng.org/issues/11332017-10-30T20:13:37ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Currently the metadata regeneration is a possibly "destructive" test, it is possible to test both kernel and ust without performing such destructive manipulation.</p>
<p>From Julien:</p>
<p>lttng start<br />lttng stop<br />echo "" to metadata file (empty it)<br />validate that babeltrace cannot read the trace (as expected)<br />lttng start<br />lttng regenerate metadata<br />lttng stop<br />validate that babeltrace is now able to read the trace.</p> LTTng-tools - Bug #1114 (New): Possible invalid discarded events counthttps://bugs.lttng.org/issues/11142017-06-01T18:54:32ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>From Issue <a class="issue tracker-1 status-8 priority-4 priority-default closed" title="Bug: Fork() test 12 from Linux Test Project fails when traced with userspace events; events are miscou... (Invalid)" href="https://bugs.lttng.org/issues/1110">#1110</a>:</p>
<pre>
Then, when running as root, the test will abort if the problem is triggered:
lttng create
lttng enable-channel -u chan_ust
lttng enable-channel -k chan_kernel
lttng add-context -u -t vpid -t ip -t procname -t vtid -c chan_ust
lttng enable-event -u -a -c chan_ust
lttng enable-event -k -c chan_kernel --syscall --all
lttng start
LD_PRELOAD=liblttng-ust-dl.so:liblttng-ust-fork.so:liblttng-ust-fd.so ./fork12
After forcibly stopping the test (^C), errors are reported and events could be miscounted when issuing lttng stop:
[warning] 9223372037047268318 events discarded, please refer to the documentation on channel configuration.
</pre>
<p>Possible source of problem is that a negative is returned somewhere. Either by kernel or ust trace.</p> LTTng-tools - Bug #1105 (New): The trigger API should warn the client when an unsupported conditi...https://bugs.lttng.org/issues/11052017-05-12T19:11:03ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Clients should be warned whenever they register a trigger that won't be evaluated. For the moment, the main use case is warning a client if a buffer usage condition is used and the lttng-modules version being used is older than 2.10.</p> LTTng-tools - Bug #1102 (In Progress): Trigger conditions are not evaluated on subscriptionhttps://bugs.lttng.org/issues/11022017-05-11T22:43:22ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Trigger conditions are not evaluated on subscription of a client. In the case of buffer usage conditions, this provides no way for clients to know the current state of the buffers.</p> LTTng-tools - Bug #1092 (New): Channel switch timers don't seem to be honoredhttps://bugs.lttng.org/issues/10922017-03-15T00:31:18ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>This bug is not confirmed, but investigating the consumer's code (see <em>consumer-timer.c</em>), it appears that the <em>live</em> and <em>switch</em> timer concepts were merged at the introduction of the live feature.</p>
<p>However, now the switch timer only seems to apply to the metadata channel. This means that there is no way for the user to force a periodical subbuffer switch in order to ensure periodical data flushes.</p> LTTng-modules - Bug #938 (Confirmed): Enabling two events with same name but not the same event t...https://bugs.lttng.org/issues/9382015-09-15T17:10:43ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<pre>
sudo lttng-sessiond -d
lttng create mysession
lttng enable-event --kernel kmem_kfree --probe sys_open+0xE
lttng enable-event --kernel kmem_kfree
lttng start
sleep 0.1
lttng stop
lttng view
</pre>
<p>Only the probe is considered when tracing. The metadata only shows the probe event.</p>
<p>This is a kernel tracer side problem (name as event key). A solution could be to prefix certain type of event on enable thus creating namespace e.g: probe_kmem_kfree.</p> LTTng-tools - Feature #749 (Confirmed): lttng list <session> should list the contexts added to ea...https://bugs.lttng.org/issues/7492014-03-07T16:36:19ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>It would be nice if the <code>lttng list <session></code> command listed the context currently added to each channel. Currently, it does not mention context at all.</p>