LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912022-10-24T21:10:59ZLTTng bugs repository
Redmine LTTng-tools - Bug #1362 (New): Listing a trigger with an event rule matches condition with a upro...https://bugs.lttng.org/issues/13622022-10-24T21:10:59ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Running against <code>d67dc273f</code>.</p>
<p>When listing triggers, I get a crash:</p>
<pre>
[root@carbonara lttng-tools]# /tmp/lttng/bin/lttng list-triggers
- name: uprobe_trigger
owner uid: 0
condition: event rule matches
rule: uprobe_trigger (type: kernel:uprobe, location type: ELF, location: tests/regression/tools/notification//../../..//utils/testapp/userspace-probe-elf-binary/.libs/userspace-probe-elf-binary:test_function)
errors: none
action:notify
lttng: ../../src/common/dynamic-array.hpp:53: void* lttng_dynamic_array_get_element(const lttng_dynamic_array*, size_t): Assertion `element_index < array->size' failed.
Aborted (core dumped)
</pre>
<p>gdb output:<br /><pre>
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/tmp/lttng/bin/lttng list-triggers'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ffbb3aa164c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffbb3aa164c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffbb3a51958 in raise () from /usr/lib/libc.so.6
#2 0x00007ffbb3a3b53d in abort () from /usr/lib/libc.so.6
#3 0x00007ffbb3a3b45c in ?? () from /usr/lib/libc.so.6
#4 0x00007ffbb3a4a486 in __assert_fail () from /usr/lib/libc.so.6
#5 0x0000564a49b9d130 in lttng_dynamic_array_get_element (array=0x564a4ab6c040, element_index=0) at ../../src/common/dynamic-array.hpp:53
#6 0x0000564a49b9d378 in lttng_action_path_copy (src=0x564a4ab6c040, dst=0x564a4ab6c540) at actions/path.cpp:110
#7 0x0000564a49b4d505 in lttng_error_query_action_create (trigger=0x564a4ab6b5d0, action_path=0x564a4ab6c040) at error-query.cpp:232
#8 0x0000564a49b3ee7c in print_action_errors (trigger=0x564a4ab6b5d0, action_path_indexes=0x0, action_path_length=0) at commands/list_triggers.cpp:765
#9 0x0000564a49b3f99a in print_one_action (trigger=0x564a4ab6b5d0, action=0x564a4ab6b4e0, action_path_indexes=0x0, action_path_length=0) at commands/list_triggers.cpp:965
#10 0x0000564a49b400c7 in print_one_trigger (trigger=0x564a4ab6b5d0) at commands/list_triggers.cpp:1123
#11 0x0000564a49b4036e in print_sorted_triggers (triggers=0x564a4ab6b110) at commands/list_triggers.cpp:1201
#12 0x0000564a49b40c92 in cmd_list_triggers (argc=0, argv=0x7fffa9404f18) at commands/list_triggers.cpp:1420
#13 0x0000564a49b438d6 in handle_command (argc=1, argv=0x7fffa9404f10) at lttng.cpp:238
#14 0x0000564a49b4402c in parse_args (argc=2, argv=0x7fffa9404f08) at lttng.cpp:427
#15 0x0000564a49b441a8 in main (argc=2, argv=0x7fffa9404f08) at lttng.cpp:476
</pre></p>
<p>This is a trigger created by the following test:<br /><code>tests/regression/tools/notification/test_notification_kernel_userspace_probe</code></p>
<p>It can be reproduced by stopping the test before invoking the event-generating application.</p> LTTng-modules - Bug #1358 (New): Failed to deploy lttng modules on NVIDIA jetson devicehttps://bugs.lttng.org/issues/13582022-09-13T13:22:48Zliuhonggang liu
<p>Hello, I installed lttng and lttng modules on NVIDIA Orin. <br />When using apt install, the results are as follows.<br /><pre><code class="shell syntaxhl" data-language="shell"><span class="c"># lttng list --kernel</span>
Error: Unable to list kernel events: Kernel tracer not available
</code></pre></p>
<pre><code class="shell syntaxhl" data-language="shell"><span class="c">#ps aux | grep lttng-sessiond</span>
root 52100 0.0 0.0 1022064 12736 ? Ssl 15:05 0:00 /usr/bin/lttng-sessiond
root 52101 0.0 0.0 41968 664 ? S 15:05 0:00 /usr/bin/lttng-sessiond
orin-d 62549 0.0 0.0 11640 684 pts/0 S+ 20:54 0:00 <span class="nb">grep</span> <span class="nt">--color</span><span class="o">=</span>auto lttng-sessiond
</code></pre>
<pre>
# dpkg -l | grep lttng
ii liblttng-ctl0:arm64 2.12.4-1~ubuntu20.04.1 arm64 LTTng control and utility library
ii liblttng-ust-ctl4:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (trace control library)
ii liblttng-ust-dev:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (development files)
ii liblttng-ust-python-agent0:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (Python agent native library)
ii liblttng-ust0:arm64 2.12.2-1~ubuntu20.04.1 arm64 LTTng 2.0 Userspace Tracer (tracing libraries)
ii lttng-modules-dkms 2.12.6-1~ubuntu20.04.1 all Linux Trace Toolkit (LTTng) kernel modules (DKMS)
ii lttng-tools 2.12.4-1~ubuntu20.04.1 arm64 LTTng control and utility programs
ii python3-lttng 2.12.4-1~ubuntu20.04.1 arm64 LTTng control and utility Python bindings
</pre>
<p>The device information is as follows.<br /><pre><code class="shell syntaxhl" data-language="shell"><span class="c"># uname -a</span>
Linux orind-d 5.10.65-tegra <span class="c">#2 SMP PREEMPT Thu Jun 16 18:24:26 CST 2022 aarch64 aarch64 aarch64 GNU/Linux</span>
</code></pre><br /><pre><code class="shell syntaxhl" data-language="shell"><span class="c"># cat /etc/os-release</span>
<span class="nv">NAME</span><span class="o">=</span><span class="s2">"Ubuntu"</span>
<span class="nv">VERSION</span><span class="o">=</span><span class="s2">"20.04.4 LTS (Focal Fossa)"</span>
<span class="nv">ID</span><span class="o">=</span>ubuntu
<span class="nv">ID_LIKE</span><span class="o">=</span>debian
<span class="nv">PRETTY_NAME</span><span class="o">=</span><span class="s2">"Ubuntu 20.04.4 LTS"</span>
<span class="nv">VERSION_ID</span><span class="o">=</span><span class="s2">"20.04"</span>
<span class="nv">HOME_URL</span><span class="o">=</span><span class="s2">"https://www.ubuntu.com/"</span>
<span class="nv">SUPPORT_URL</span><span class="o">=</span><span class="s2">"https://help.ubuntu.com/"</span>
<span class="nv">BUG_REPORT_URL</span><span class="o">=</span><span class="s2">"https://bugs.launchpad.net/ubuntu/"</span>
<span class="nv">PRIVACY_POLICY_URL</span><span class="o">=</span><span class="s2">"https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"</span>
<span class="nv">VERSION_CODENAME</span><span class="o">=</span>focal
<span class="nv">UBUNTU_CODENAME</span><span class="o">=</span>focal
</code></pre></p>
<p>At the same time, I tried the method of source code, such as the source code installation method introduced in <a class="external" href="https://lttng.org/docs/v2.13/">https://lttng.org/docs/v2.13/</a>.<br /><pre>
# dpkg -l | grep -e libuuid -e popt -e userspace -e libxml2
ii can-utils 2018.02.0-1ubuntu1 arm64 SocketCAN userspace utilities and tools
ii dmsetup 2:1.02.167-1ubuntu1 arm64 Linux Kernel Device Mapper userspace library
ii gvfs:arm64 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - GIO module
ii gvfs-backends 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - backends
ii gvfs-bin 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - deprecated command-line tools
ii gvfs-common 1.44.1-1ubuntu1 all userspace virtual filesystem - common data files
ii gvfs-daemons 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - servers
ii gvfs-fuse 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - fuse server
ii gvfs-libs:arm64 1.44.1-1ubuntu1 arm64 userspace virtual filesystem - private libraries
ii libdevmapper1.02.1:arm64 2:1.02.167-1ubuntu1 arm64 Linux Kernel Device Mapper userspace library
ii libi2c0:arm64 4.1-2build2 arm64 userspace I2C programming library
ii libibverbs1:arm64 28.0-1ubuntu1 arm64 Library for direct userspace use of RDMA (InfiniBand/iWARP)
ii libnftnl11:arm64 1.1.5-1 arm64 Netfilter nftables userspace API library
ii libpopt-dev:arm64 1.16-14 arm64 lib for parsing cmdline parameters - development files
ii libpopt0:arm64 1.16-14 arm64 lib for parsing cmdline parameters
ii liburcu-dev:arm64 0.12.2-1~ubuntu20.04.2 arm64 userspace RCU (read-copy-update) library - development files
ii liburcu6:arm64 0.12.2-1~ubuntu20.04.2 arm64 userspace RCU (read-copy-update) library
ii libusb-1.0-0:arm64 2:1.0.23-2build1 arm64 userspace USB programming library
ii libusb-1.0-0-dev:arm64 2:1.0.23-2build1 arm64 userspace USB programming library development files
ii libuuid1:arm64 2.34-0.1ubuntu9.3 arm64 Universally Unique ID library
ii libxml2:arm64 2.9.10+dfsg-5ubuntu0.20.04.1 arm64 GNOME XML library
ii libxml2-dev:arm64 2.9.10+dfsg-5ubuntu0.20.04.1 arm64 Development files for the GNOME XML library
ii libxml2-utils 2.9.10+dfsg-5ubuntu0.20.04.3 arm64 XML utilities
ii network-manager 1.22.10-1ubuntu2.3 arm64 network management framework (daemon and userspace tools)
ii nvidia-l4t-optee 34.1.0-20220406120854 arm64 OP-TEE userspace daemons, test programs and libraries
ii python3-lxml:arm64 4.5.0-1ubuntu0.5 arm64 pythonic binding for the libxml2 and libxslt libraries
</pre></p>
<pre>
sudo ln -snf /usr/src/linux-headers-5.10.65-tegra-ubuntu20.04_aarch64/kernel-5.10 /lib/modules/5.10.65-tegra/build
</pre>
<pre>
# orin-d@orind-d:~/tmp/lttng-modules-2.13.5$ make
/home/orin-d/tmp/lttng-modules-2.13.5/src/wrapper/kallsyms.c:20:3: error: #error "LTTng-modules requires CONFIG_KPROBES on kernels >= 5.7.0"
20 | # error "LTTng-modules requires CONFIG_KPROBES on kernels >= 5.7.0"
| ^~~~~
make[2]: *** [scripts/Makefile.build:281: /home/orin-d/tmp/lttng-modules-2.13.5/src/wrapper/kallsyms.o] Error 1
make[1]: *** [Makefile:1852: /home/orin-d/tmp/lttng-modules-2.13.5/src] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.65-tegra-ubuntu20.04_aarch64/kernel-5.10'
make: *** [Makefile:31: modules] Error 2
</pre> LTTng - Feature #1347 (New): Codename for 2.14https://bugs.lttng.org/issues/13472022-03-01T20:27:38ZMichael Jeansonmjeanson@efficios.com
<p>What should the codename of the LTTng 2.14 release be?</p>
<p>Must be a micro-brewed Quebec beer and start with a "O".</p> 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 - Bug #1182 (New): relayd mishandles channels configured with tracefile-count == 0 an...https://bugs.lttng.org/issues/11822019-04-02T17:25:50ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Relayd mistakenly considers that the criterion tracefile-count == 0 means no tracefile rotation should happen for the stream.</p>
<p>However, it's possible that tracefile-size is set to non-zero, but tracefile-count is left at its default value of 0.</p>
<p>The expected behavior would be to have an ever increasing counter (no limit) of tracefiles each "size" in size at most.</p>
<p>I suspect the relayd receiving side may also be broken, because its rotation handling code also has the same incorrect assumptions.</p>
<p>When connecting a live client to such a session, we get on the client side:<br />[error] Remote side has closed connection</p>
<p>And a PERROR on relayd:<br />PERROR - 13:16:28.097800421 [8061/8068]: opening index in read-only: No such file or directory (in lttng_index_file_open() at index.c:261)</p>
<p>Likely caused by confusion between tracefile rotation suffixes in the filename.</p> 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-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 #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 #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-tools - Bug #1068 (New): lttng-ctl: lttng_load_session_attr_get_override_ctrl_url() returns...https://bugs.lttng.org/issues/10682016-10-07T21:11:45ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>lttng_load_session_attr_get_override_ctrl_url() returns NULL when the destination override is set using lttng_load_session_attr_set_override_url() since the three destination override setters use a scheme where they store a "raw_*" version of the strings provided by the user.</p>
<p>However, lttng_load_session_attr_get_override_ctrl_url() should arguably return a control URL when lttng_load_session_attr_set_override_url() did set a network destination using the LTTng URL format (with two ports).</p> LTTng-tools - Bug #1033 (New): lttng load does not preserve event or channel orderinghttps://bugs.lttng.org/issues/10332016-06-16T17:28:29ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p><code>lttng load</code> builds the channel and event lists as if they were entered using <code>enable-channel</code> and <code>enable-event</code> commands, in the order that they appear in the <code>.lttng</code> file. Internally, these lists are built in stack-like fashion, each addition pushing the already-entered channels or events down and inserting the new channel or event at the head of the list. <code>lttng save</code>, on the other hand, writes the channels and events to the <code>.lttng</code> file in the same order that they appear in the internal lists, starting at each list's head. This means an <code>lttng load</code> - <code>lttng save</code> cycle will completely invert the channel and event ordering within the <code>.lttng</code> file.</p>
<p>This normally matters little, but it should be noted that an event list (for instance) can be optimized against lookup by ensuring the most-frequently requested events appear at the head of the list. A user that fine-tuned his <code>.lttng</code> files in this way would understandably be upset that <code>lttng load</code> inverts the order.</p>
<p>This can be fixed by having the <code>lttng load</code> routine read each XML enumeration into a buffer, issuing the LTTng list-addition commands in last-to-first order. Since the XML enumerations in the <code>.lttng</code> files are nested, recursion is required and the desired corrected behaviour can be achieved by having the list-addition commands appear in the popping phase of the recursion.</p>
<p>Note that domain ordering is preserved by <code>lttng load</code>.</p>