LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912023-08-16T18:53:52ZLTTng bugs repository
Redmine LTTng - Bug #1385 (Feedback): [lttng-live] error: recevie a message in the pasthttps://bugs.lttng.org/issues/13852023-08-16T18:53:52ZBin Yuan
<p>My program works well most of time. But in rare case, it reports the following hightling error.<br /><img src="https://bugs.lttng.org/attachments/download/572/clipboard-202308170250-vfley.jpg" alt="" loading="lazy" /></p>
<p>What will lead to those branch? any suggestion to debug?</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 #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> LTTng - Bug #1315 (Feedback): Kernel panics after `pkill lttng`; root session daemon has active t...https://bugs.lttng.org/issues/13152021-05-07T20:09:26ZPhilippe Proulxeeppeliteloop@gmail.com
<p>I don't know how to reproduce this bug.</p>
<p>I played with the <code>lttng add-trigger</code> command while writing usage examples for its manual page.</p>
<p>I started the root session daemon as such:</p>
<pre>
# lttng-sessiond --daemonize --group=eepp
</pre>
<p>I then ran commands such as:</p>
<pre>
$ lttng add-trigger --name user --condition=event-rule-matches --domain=user --action=notify
</pre>
<pre>
$ lttng add-trigger --condition=event-rule-matches \
--domain=user --action=notify \
--rate-policy=every:10
</pre>
<pre>
$ lttng add-trigger --owner-uid=33 \
--condition=event-rule-matches \
--domain=kernel --name='sched*' \
--action=notify
</pre>
<pre>
$ lttng add-trigger --condition=event-rule-matches \
--domain=kernel --type=syscall \
--filter='fd < 3' \
--action=start-session my-session \
--rate-policy=once-after:40
</pre>
<p>Note that I had no tracing session named <code>my-session</code>.</p>
<p>After a few minutes, Xorg froze. I managed to login again in a virtual console. I ran:</p>
<pre>
# pkill lttng
</pre>
<p>and got an instant kernel panic.</p>
<p>Attached is a photo of what was on the screen after running <code>pkill</code>.</p>
<p>Using:</p>
<ul>
<li>LTTng-tools <code>60860e547ce31ea629e846e00b66342425474b8d</code>.</li>
<li>LTTng-UST <code>a0f2513af262a19822d46f84cd5e34be0badc484</code></li>
<li>LTTng-modules <code>51ef453614a6db2b778595b16d93283d25db974a</code></li>
<li>liburcu <code>5e1b7c840a2b21b8442b322cedbb70a790e49520</code></li>
</ul> LTTng - Feature #1269 (New): Document clearly the versioning scheme of lttng-projects.https://bugs.lttng.org/issues/12692020-05-22T19:42:08ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Correct me if I am wrong but it is an "unwritten" rule that we follow semver [1]. Some organization might appreciate that we state clearly our versioning policy.</p>
<p>[1] <a class="external" href="https://semver.org/">https://semver.org/</a></p> LTTng - Feature #1268 (New): Adopting a Vulnerability Disclosure Policy for our projectshttps://bugs.lttng.org/issues/12682020-05-22T19:27:49ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Some organization might require/appreciate such policy.</p>
<p>We could probably base our policy on <a class="external" href="https://disclose.io/">https://disclose.io/</a>, considering they have "terms" [1] with canada in mind.</p>
<p>[1] <a class="external" href="https://github.com/disclose/disclose/tree/master/terms">https://github.com/disclose/disclose/tree/master/terms</a></p>
<p>IANAL</p> LTTng-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-tools - Bug #994 (Confirmed): Configured metadata data channel not listed for UST domainhttps://bugs.lttng.org/issues/9942016-01-27T16:17:44ZBernd HufmannBernd.Hufmann@ericsson.com
<p>I noticed this for LTTng 2.7 and 2.6.</p>
<p>After configuring the metadata channel for UST, the metadata channel is not listed when listing the session. By the way, it works for the kernel domain.</p>
<p>To reproduce:</p>
<blockquote>
<p>lttng create my<br />lttng enable-channel metadata -u -s my --subbuf-size 65536<br />lttng list my</p>
</blockquote>
<p>Tracing session my: [inactive]<br /> Trace path: /home/user/lttng-traces/my-20160127-105230</p>
<p>=== Domain: UST global ===</p>
<p>Buffer type: per UID</p> LTTng-tools - Bug #987 (Confirmed): Incomplete string comparison patternhttps://bugs.lttng.org/issues/9872016-01-06T23:23:31ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>In a few instances in lttng-tools, a string comparison pattern involving strncmp and strlen() to limit the length of the comparison is used.</p>
<p>One can quickly find them with:</p>
<p>grep -r -A 3 strncmp . | less -> search for strlen or strnlen</p>
<p>Many of those are OK: they indeed only want to match the beginning of the strings. However, this pattern is incorrectly used in cases where a full match is required, for instance:</p>
<p>ust-registry.c:ht_match_event()<br />./src/bin/lttng/commands/enable_channels.c: if (!strncmp(output_mmap, opt_output, strlen(output_mmap))) {<br />./src/bin/lttng/commands/enable_channels.c: } else if (!strncmp(output_splice, opt_output, strlen(output_splice))) {<br />./src/bin/lttng-sessiond/snapshot.c: if (!strncmp(output->name, name, strlen(name))) {</p> LTTng-tools - Feature #986 (New): Warn when unreasonably short timer values are usedhttps://bugs.lttng.org/issues/9862016-01-05T22:35:59ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Most timer configuration options are expressed in microseconds which makes it easy for users to specify an unreasonably short intervals of time. These configuration mistakes result in unusually high tracing overhead and may be quite challenging to figure out for inexperienced users.</p>
<p>The lttng client should warn when timers are set to very low values.</p> LTTng-modules - Feature #950 (New): Exclude specific kernel events when enabling all of themhttps://bugs.lttng.org/issues/9502015-10-09T22:55:29ZJulien Desfossezjdesfossez@efficios.com
<p>It would be nice to be able to do that (like in UST):<br />lttng enable-event -k -a --exclude sched_switch</p>
<p>My current workaround:<br />lttng enable-event <del>k $(lttng list -k | grep -v -E "Kernel|---</del>" | grep -v sched_switch | awk '{print $1}' | tr "\n" ",")</p> LTTng-tools - Feature #932 (Confirmed): LTTng client error code semantics are ill-definedhttps://bugs.lttng.org/issues/9322015-09-05T16:34:01ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>The LTTNG (1) man page mentions that</p>
<pre>
On success 0 is returned and a positive value on error. Value of 1 means a command error, 2 an undefined command, 3 a fatal error and 4 a command warning meaning that something went wrong during the command.
Any other value above 10, please refer to <lttng/lttng-error.h> for a detailed list or use lttng_strerror() to get a human readable string of the error code.
</pre>
<p>There are a number of things wrong with this. First of all, asking script authors to check some obscure error header deep in the bowels of their system is questionable, at best.</p>
<p>Second, as remarked by Michael Jeanson, Philippe Proulx, most command-line utilities don't return an error code to indicate a warning. A non-zero error code means an error as occurred.</p>
<p>We will have to go through commands and determine which errors are in fact harmless warnings (e.g. enabling the same event twice), and which ones shall signal an error (e.g. invalid channel configuration).</p> LTTng-tools - Bug #901 (In Progress): Some liblttng-ctl don't return LTTNG_OK on successhttps://bugs.lttng.org/issues/9012015-08-05T18:26:10ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>It appears that some liblttng-ctl functions, such as lttng_create_session_snapshot() have conflicting return code conventions.</p>
<p>In this specific case, the header under lttng/session.h asserts that the function will<br /><pre>
/*
[...]
* Return 0 on success else a negative LTTng error code.
*/
</pre></p>
<p>while the header in lttng-ctl.c affirms that it<br /><pre>
/*
[...]
* Returns LTTNG_OK on success or a negative error code.
*/
</pre></p>
<p>and the function actually returns<br /><pre>
ret = lttng_ctl_ask_sessiond_varlen(&lsm, uris, ...
</pre></p>
<p>which, itself will<br /><pre>
/*
[...]
Return size of data (only payload, not header) or a negative error code.
*/
</pre></p>
<p>This pattern is used in multiple places which breaks code which checks for "ret == LTTNG_OK" instead of "ret < 0".</p>