LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912023-12-19T20:03:54ZLTTng bugs repository
Redmine LTTng-tools - Bug #1407 (New): Hang when stopping a live session with a low live valuehttps://bugs.lttng.org/issues/14072023-12-19T20:03:54ZKienan Stewart
<p>While investigating <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Investigate why events are no longer recorded by the live view when `DELAYUS` in `tests/regressio... (Resolved)" href="https://bugs.lttng.org/issues/1403">#1403</a>, I noticed some test runs would intermittently hang when the live delay value was set very low (eg. 1us).</p>
<p>For example, in <code>tests/regression/tools/clear/test_ust</code> the test <code>test_ust_streaming_live</code> would hang executing <code>lttng stop sessionX</code>. After investigating the issue I noted the following:</p>
<ul>
<li>the lttng client is hanging, pending a response from the sessiond</li>
<li>the consumer's consumer_thread_data_poll thread appear to be looping in <code>consumer_timer_signal_thread_qs</code> while trying to remove the monitor timer during channel deletion: <pre>
Thread 7 (Thread 0x7f999bfff680 (LWP 3060295) "lttng-consumerd"):
#0 sigpending (set=0x7f999bffdea0) at ../sysdeps/unix/sysv/linux/sigpending.c:27
#1 0x00005559299f07ec in consumer_timer_signal_thread_qs (signr=47) at consumer/consumer-timer.cpp:325
#2 consumer_channel_timer_stop (timer_id=timer_id@entry=0x7f998c0021c0, signal=47) at consumer/consumer-timer.cpp:422
#3 0x00005559299f122f in consumer_timer_monitor_stop (channel=channel@entry=0x7f998c000f40) at consumer/consumer-timer.cpp:531
#4 0x00005559299dabbf in consumer_del_channel (channel=channel@entry=0x7f998c000f40) at consumer/consumer.cpp:379
#5 0x00005559299ee83a in consumer_stream_destroy (stream=stream@entry=0x7f998c01a830, ht=<optimized out>) at consumer/consumer-stream.cpp:1070
#6 0x00005559299e3c61 in consumer_del_stream (ht=<optimized out>, stream=0x7f998c01a830) at consumer/consumer.cpp:547
#7 consumer_thread_data_poll (data=0x55592b498ba0) at consumer/consumer.cpp:2747
#8 0x00007f99aaaa63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
#9 0x00007f99aab26a5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
</pre></li>
<li>the consumerd's consumer_timer_thread was often handling the live timer: <pre>
Thread 4 (Thread 0x7f99a991b680 (LWP 3060292) "lttng-consumerd"):
#0 __GI___libc_write (nbytes=124, buf=0x7f99a9919e90, fd=2) at ../sysdeps/unix/sysv/linux/write.c:26
#1 __GI___libc_write (fd=2, buf=0x7f99a9919e90, nbytes=124) at ../sysdeps/unix/sysv/linux/write.c:24
#2 0x00007f99aaa9dbb5 in _IO_new_file_write (f=0x7f99aabf26a0 <_IO_2_1_stderr_>, data=0x7f99a9919e90, n=124) at ./libio/fileops.c:1180
#3 0x00007f99aaa9cf70 in new_do_write (fp=fp@entry=0x7f99aabf26a0 <_IO_2_1_stderr_>, data=data@entry=0x7f99a9919e9
0 "DBG1 - 10:31:33.730698608 [3060287/3060292]: Live timer for channel 17 (in live_timer() at consumer/consumer-timer.cpp:284)\n", to_do=to_do@entry=124) at ./libio/libioP.h:946
#4 0x00007f99aaa9e2a1 in _IO_new_file_xsputn (n=124, data=<optimized out>, f=0x7f99aabf26a0 <_IO_2_1_stderr_>) at ./libio/fileops.c:1254
#5 _IO_new_file_xsputn (f=0x7f99aabf26a0 <_IO_2_1_stderr_>, data=<optimized out>, n=124) at ./libio/fileops.c:1196
#6 0x00007f99aaa71409 in __printf_buffer_flush_to_file (buf=buf@entry=0x7f99a9919e60) at ../libio/libioP.h:946
#7 0x00007f99aaa714c0 in __printf_buffer_to_file_done (buf=buf@entry=0x7f99a9919e60) at ./stdio-common/printf_buffer_to_file.c:120
#8 0x00007f99aaa7ac0d in __vfprintf_internal (s=0x7f99aabf26a0 <_IO_2_1_stderr_>, format=0x555929a57cd8 "DBG1 - %s [%s]: Live timer for channel %lu (in %s() at consumer/consumer-timer.cpp:284)\n", ap=ap@entry=0x7f99a9919f60, mode_
flags=mode_flags@entry=0) at ./stdio-common/vfprintf-internal.c:1475
#9 0x00007f99aaa70296 in __fprintf (stream=<optimized out>, format=<optimized out>) at ./stdio-common/fprintf.c:32
#10 0x00005559299f2280 in live_timer (si=0x7f99a991a160, ctx=0x55592b498ba0) at consumer/consumer-timer.cpp:284
#11 consumer_timer_thread (data=0x55592b498ba0) at consumer/consumer-timer.cpp:789
#12 0x00007f99aaaa63ec in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
#13 0x00007f99aab26a5c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
</pre></li>
</ul>
<p><code>consumer_timer_signal_thread_qs</code> is busy loop until the the the signal in question is no longer pending. In <code>consumer-timer.cpp::consumer_timer_thread</code>, the signals are waited on by <code>sigwaitinfo</code>, and there are some ordering rules (see man 7 signal):</p>
<ul>
<li>for RT signals, by signal priority</li>
<li>for standard signals, an unspecified order</li>
<li>in Linux standard signals are delivered before RT signals</li>
</ul>
<p>The signal priorities are their signal number as defined [[<a class="external" href="https://github.com/lttng/lttng-tools/blob/dff46b736afb7945aaf635de661b920dd0d01d7f/src/common/consumer/consumer-timer.hpp#L17|here">https://github.com/lttng/lttng-tools/blob/dff46b736afb7945aaf635de661b920dd0d01d7f/src/common/consumer/consumer-timer.hpp#L17|here</a>]]. Lower values have a higher priority.</p>
<p>When the live session is configured with a low delay, eg <code>--live=1</code>, the live timer is firing relatively rapidly and can prevent the signal fired by the monitor timer from being handled. This in turn means that the session destruction may hang until (hopefully) the monitor signal is handled and no longer pending.</p>
<p>A few options were discussed:</p>
<ul>
<li>changing signal ordering (eg. reducing the priority of live signal): while it would address this particular case, it then means a session with a low value for the monitor timer could equally starve out the handling of the live timer's signal</li>
<li>using <code>sigpending</code> in combination with <code>sigwaitinfo</code>: while it's possible to get all pending signals as a set, it seems to not be possible to retrieve the details (<code>siginfo_t</code>) which are required some some data (eg. pointers) to properly handle the signal</li>
<li>signalfd: very linux specific</li>
<li>timer_fd: very linux specific</li>
<li>custom scheduler: eg., <a class="external" href="https://github.com/nsec/badge-conf-2023/blob/nsec2023/lib/scheduling/scheduler.hpp">https://github.com/nsec/badge-conf-2023/blob/nsec2023/lib/scheduling/scheduler.hpp</a></li>
<li>switch from using channel pointers in the <code>sigval_ptr</code> to passing IDs that can be used for lookups which may fail gracefully instead; that way the pending signals wouldn't have to all be cleared in <code>consumer_timer_signal_thread_qs</code></li>
</ul>
<p>It seems the most promising path is to implement a small deadline scheduler.</p> LTTng-tools - Bug #1402 (New): Some files are missing REUSE licensing and copyright informationhttps://bugs.lttng.org/issues/14022023-11-14T15:03:06ZPhilippe Proulxeeppeliteloop@gmail.com
<p>Running <code>reuse lint</code> at the root of the source tree reveals many files are missing copyright and/or license information (SPDX):</p>
<blockquote>
<p>Unfortunately, your project is not compliant with version 3.0 of the REUSE Specification :-(</p>
</blockquote>
<p>This includes pretty much all the <code>Makefile.am</code> and <code>*.m4</code> files as well as <code>src/vendor/fmt/*</code>, <code>src/vendor/msgpack/*</code>, and <code>src/vendor/optional.hpp</code>.</p>
<p>Note that to keep vendor files unmodified, you may use the <code>.license</code> or <code>.reuse/dep5</code> <a href="https://reuse.software/spec/" class="external">strategies</a>.</p> LTTng-tools - Bug #1379 (New): Document behavior of live mode with per-pid UST buffershttps://bugs.lttng.org/issues/13792023-06-01T18:48:58ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>There is a design limitation of per-pid UST buffers when used in live mode which should be documented.</p>
<p>Basically, because the per-pid buffers are reclaimed soon after the application exits, it may cause the events traced by a short-lived application to never appear in the output of a live trace when per-pid buffers are used.</p>
<p>This is caused by the fact that the live client periodically checks for new buffers, but there is no inherent reference kept on the streams before they disappear.</p>
<p>This means that the information will be available in the disk output of the trace, but it will be missing from the live mode output.</p>
<p>This could eventually be mitigated by keeping references to the streams received by the relay daemon which are of interest to a live client until they are referenced by the live client.</p> LTTng-tools - Bug #1378 (New): Document behavior of snapshot mode with per-pid UST buffershttps://bugs.lttng.org/issues/13782023-06-01T18:01:12ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We should document a design limitation of the per-pid UST buffers which can lead to unexpected results when used with the "snapshot" feature.</p>
<p>Basically, because the per-pid buffers lifetime is bound by the application using them (and the consumer daemon extracting data from them), they are freed almost immediately after the traced application exits. However, in a scenario where we are interested in capturing a snapshot of the content of flight recorder buffers soon after application exits (e.g. caused by a crash), those buffers are not available anymore a few milliseconds after the application exits.</p>
<p>We should document this design limitation, and eventually think about improvements (feature request ?) to allow a configurable delay after application exit during which the consumer daemon could keep references on the buffers so they are available for snapshot.</p> 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-tools - Bug #1342 (New): Rotation thread's handling of session consumed size notifications ...https://bugs.lttng.org/issues/13422021-12-09T21:40:35ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Related to this change:<br /><a class="external" href="https://review.lttng.org/c/lttng-tools/+/6886/">https://review.lttng.org/c/lttng-tools/+/6886/</a></p>
The race described in that change has another consequence: the notification could refer to a different session instance of the same name:
<ul>
<li>notification emitted for session <code>foo</code>,</li>
<li>session <code>foo</code> is destroyed,</li>
<li>a new session named <code>foo</code> is created,</li>
<li>a rotation is triggered for <code>foo</code>.</li>
</ul>
There are multiple solutions for this:
<ul>
<li>Provide a unique session id as part the of the evaluation of <code>SESSION_CONSUMED_SIZE</code>,</li>
<li>Register an internal trigger that has the <code>rotate session</code> action (since ids are sampled during their handling).</li>
</ul>
<p>I can't work on a fix right now, but here is a placeholder patch that will eventually contain the fix:<br /><a class="external" href="https://review.lttng.org/c/lttng-tools/+/6907">https://review.lttng.org/c/lttng-tools/+/6907</a></p>
<p>This is hypothetical and I noticed it during a code review; nobody reported this problem.</p> LTTng-tools - Bug #1340 (New): Document behavior of per-uid UST buffers with respect to asynchron...https://bugs.lttng.org/issues/13402021-12-07T20:22:28ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We should document a known design limitation of the per-uid UST buffers:</p>
<p>When using lttng-ust with per-uid buffers, there is a known design limitation<br />regarding process terminated by non-handled kill signals: if this occurs while<br />the buffer is being written to (between reserve and commit), it will cause the<br />rest of the per-cpu buffer to be unreadable. This applies to all events<br />recorded by all applications of the same user id for that particular CPU.<br />Recovering from this involves destroying and re-creating the tracing session.</p>
<p>If this kind of scenario is likely for you, you might want to consider using per-<br />pid buffers (lttng enable-channel -u --buffers-pid), which do not suffer from<br />this design limitation. The downside of per-pid buffers is that it allocates<br />more memory on your system for buffering, and adds extra overhead when<br />used with processes that have a short life-time.</p> LTTng-tools - Bug #1324 (New): lttng_enable_event() and lttng_enable_event_with_filter() cannot a...https://bugs.lttng.org/issues/13242021-08-24T19:48:46ZPhilippe Proulxeeppeliteloop@gmail.com
<p>Currently:</p>
<ul>
<li><code>lttng_enable_event()</code> calls <code>lttng_enable_event_with_exclusions()</code>, passing no filter expression and no event name exclusion patterns.</li>
<li><code>lttng_enable_event_with_filter()</code> calls <code>lttng_enable_event_with_exclusions()</code>, passing no event name exclusion patterns.</li>
</ul>
<p>This means that if you want to enable a recording event rule described with a filter expression and event name exclusion patterns, you need to:</p>
<ol>
<li>Get the filter expression from its descriptor with <code>lttng_event_get_filter_expression()</code>.</li>
<li>Build an array of event name exclusion patterns, getting them from its descriptor with <code>lttng_event_get_exclusion_name_count()</code> and <code>lttng_event_get_exclusion_name()</code>.</li>
<li>Call <code>lttng_enable_event_with_exclusions()</code>.</li>
</ol>
<p>This is what you would need to do to blindly enable a disabled recording event rule of which the descriptor comes from <code>lttng_list_events()</code>.</p>
<p><code>lttng_enable_event()</code> and <code>lttng_enable_event_with_filter()</code> could do the steps above for you, if this doesn't break any backward compatibility.</p> Babeltrace - Bug #1295 (New): Copy-pasto in bt_value_map_borrow_entry_value dochttps://bugs.lttng.org/issues/12952020-12-15T05:54:56ZSimon Marchisimon.marchi@polymtl.ca
<p>Here:</p>
<p><a class="external" href="https://babeltrace.org/docs/v2.0/libbabeltrace2/group__api-val.html#gaf3e38ff6931760cf4dc56ca0c8354f02">https://babeltrace.org/docs/v2.0/libbabeltrace2/group__api-val.html#gaf3e38ff6931760cf4dc56ca0c8354f02</a></p>
<p>It says <code>value is an array value (bt_value_is_array() returns BT_TRUE).</code>. Should be map, not array.</p> Babeltrace - Bug #1289 (New): docs: document that the "notext" flag is required to build out of t...https://bugs.lttng.org/issues/12892020-11-04T22:06:23ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>This is related to the gerrit change <a href="https://review.lttng.org/c/babeltrace/+/4228" class="external">4228</a></p>
<p>When building an out-of-tree plug-in, users of LLVM ld (freeBSD, but also maybe macOS?) must ensure they pass the 'notext' flag.<br />See the discussion on the gerrit change for more context.</p>
<p>This should probably be documented under <a href="https://github.com/efficios/babeltrace/blob/43c59509042845f8d42c3e99ec74d45fa2dc0908/doc/api/libbabeltrace2/dox/guides.dox#L101" class="external">Compile and link a Babeltrace 2 shared object plugin of guides.dox</a></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-UST - Bug #1203 (New): Improve documentation of lttng-ust with daemonshttps://bugs.lttng.org/issues/12032019-10-07T15:51:26ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>The lttng-ust(3) man page should be clarified regarding the scenarios where the liblttng-ust-fork.so wrapper is needed.</p>
<p>It should document that it is needed in scenarios where applications using fork(2), clone(2) (with CLONE_VM flag cleared), BSD's rfork(2), daemon(3), without <strong>immediately</strong> following those by an exec(3) family call. This includes scenarios where close(2) is used to close file descriptors before invoking exec(3), even though close(2) is listed as an async-signal-safe function.</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 - Bug #1072 (New): configure does not check for needed Libxml2 symbolshttps://bugs.lttng.org/issues/10722016-11-01T09:09:00ZPhilippe Proulxeeppeliteloop@gmail.com
<p>LTTng-tools's <code>configure</code> script checks for the existence and version of Libxml2 with pkg-config, but it does not check for the exact needed symbols. Libxml2 has a lot of <code>--with-</code> configuration options, some of which can disable modules that LTTng-tools needs.</p>
<p>I suggest that we check one selected symbol per module. This should ensure that at least the module exists, which should guarantee that the other symbols are available too.</p>
<p>It looks like the following Libxml2 configuration options enable the needed modules:</p>
<pre>
--with-minimum --with-sax1 --with-tree --with-writer --with-schemas
</pre>
<ul>
<li><code>--with-minimum</code> simply "resets" the enabled modules to none.</li>
<li><code>--with-sax1</code> is needed for basic XML parsing (load).</li>
<li><code>--with-tree</code> is needed for querying an XML document as a tree (load).</li>
<li><code>--with-writer</code> is needed for writing XML (save, MI).</li>
<li><code>--with-schemas</code> is needed for XML validation (load).</li>
</ul>
<p>All those options are available in the Libxml2 2.7.6 release (minimum required version by LTTng-tools).</p>