LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912023-08-31T15:51:05ZLTTng bugs repository
Redmine Babeltrace - Bug #1387 (Resolved): sink.ctf.fs is not quiet by defaulthttps://bugs.lttng.org/issues/13872023-08-31T15:51:05ZThomas Applencourt
```
<ol>
<li>Quiet True<br />applenco@polaris-login-01:~> babeltrace2 \</li>
</ol>
<blockquote>
<p>--component source.ctf.fs \<br />--params "inputs=[\"/home/applenco/lttng-traces/iprof-20230831-154527/0/ust/uid/32658/64-bit/\"]" \<br />--component sink.ctf.fs \<br />--params "path=\"/home/applenco/whatever/\",assume-single-trace=false,quiet=false"</p>
</blockquote>
Created CTF trace `/home/applenco/whatever//polaris-login-01/THAPI_0-20230831T154517+0000/ust/uid/32658/64-bit-0`.
<ol>
<li>Quiet True<br />applenco@polaris-login-01:~> babeltrace2 --component source.ctf.fs --params "inputs=[\"/home/applenco/lttng-traces/iprof-20230831-154527/0/ust/uid/32658/64-bit/\"]" --component sink.ctf.fs --params "path=\"/home/applenco/whatever/\",assume-single-trace=false,quiet=yes" </li>
<li>Quiet default<br />applenco@polaris-login-01:~> babeltrace2 --component source.ctf.fs --params "inputs=[\"/home/applenco/lttng-traces/iprof-20230831-154527/0/ust/uid/32658/64-bit/\"]" --component sink.ctf.fs --params "path=\"/home/applenco/whatever/\",assume-single-trace=false" <br />Created CTF trace `/home/applenco/whatever//polaris-login-01/THAPI_0-20230831T154517+0000/ust/uid/32658/64-bit-2`.<br />```</li>
</ol>
<p>The documentation (<a class="external" href="https://babeltrace.org/docs/v2.0/man7/babeltrace2-sink.ctf.fs.7/#doc-param-quiet">https://babeltrace.org/docs/v2.0/man7/babeltrace2-sink.ctf.fs.7/#doc-param-quiet</a>) specify that the default should be `quiet=yes / true`</p> Babeltrace - Bug #1276 (Resolved): Empty ctf_sequence(uint64_t) on aarch64 makes babeltrace failhttps://bugs.lttng.org/issues/12762020-07-21T11:49:45ZStefan Schuermans
<a name="Empty-ctf_sequenceuint64_t-on-aarch64-makes-babeltrace-fail"></a>
<h1 >Empty ctf_sequence(uint64_t) on aarch64 makes babeltrace fail<a href="#Empty-ctf_sequenceuint64_t-on-aarch64-makes-babeltrace-fail" class="wiki-anchor">¶</a></h1>
<p>I am using LTTng 2.12 (liblttng-ust0 2.12.0, lttng-modules 2.12.1) on aarch64 Linux version 4.9.140-tegra to trace sequences of <code>uint64_t</code> from userspace (<code>unsigned int</code> for the length of the sequence). When a sequence is empty, the resulting CTF data cannot be parsed by babeltrace in most cases.</p>
<pre>
[error] Unexpected end of packet. Either the trace data stream is corrupted or metadata description does not match data layout.
[error] Reading event failed.
Error printing trace.
</pre>
<a name="System-and-OS-Details"></a>
<h2 >System and OS Details<a href="#System-and-OS-Details" class="wiki-anchor">¶</a></h2>
<p>System and OS details:<br /><pre>
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
$ uname -a
Linux jetson-tx2-tb31 4.9.140-tegra #1 SMP PREEMPT Mon Dec 9 22:52:02 PST 2019 aarch64 aarch64 aarch64 GNU/Linux
$ lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 6
On-line CPU(s) list: 0,3-5
Off-line CPU(s) list: 1,2
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 3
Model name: Cortex-A57
Stepping: r1p3
CPU max MHz: 2035,2000
CPU min MHz: 345,6000
BogoMIPS: 62.50
L1d cache: 32K
L1i cache: 48K
L2 cache: 2048K
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32
$ lttng --version
lttng (LTTng Trace Control) 2.12.1 - (Ta) Meilleure
$ dpkg --list | grep lttng
ii liblttng-ctl-dev:arm64 2.12.1-1 arm64 LTTng control and utility library (development files)
ii liblttng-ctl0:arm64 2.12.1-1 arm64 LTTng control and utility library
ii liblttng-ust-ctl4:arm64 2.12.0-2 arm64 LTTng 2.0 Userspace Tracer (trace control library)
ii liblttng-ust-dev:arm64 2.12.0-2 arm64 LTTng 2.0 Userspace Tracer (development files)
ii liblttng-ust-python-agent0:arm64 2.12.0-2 arm64 LTTng 2.0 Userspace Tracer (Python agent native library)
ii liblttng-ust0:arm64 2.12.0-2 arm64 LTTng 2.0 Userspace Tracer (tracing libraries)
ii lttng-modules-dkms 2.12.1-1slx4806 all Linux Trace Toolkit (LTTng) kernel modules (DKMS)
ii lttng-tools 2.12.1-1 arm64 LTTng control and utility programs
$ babeltrace --help | head -n 1
BabelTrace Trace Viewer and Converter 1.5.5
$ dpkg --list | grep babel
ii babeltrace 1.5.5-1 arm64 Trace conversion program
ii libbabeltrace-dev:arm64 1.5.5-1 arm64 Babeltrace development files
ii libbabeltrace1:arm64 1.5.5-1 arm64 Babeltrace conversion libraries
(I also tried more recent babeltrace versions, see below.)
</pre></p>
<a name="How-to-Reproduce"></a>
<h2 >How to Reproduce<a href="#How-to-Reproduce" class="wiki-anchor">¶</a></h2>
<p>This is my tracepoint definition:</p>
<pre>
#include <stdint.h>
TRACEPOINT_EVENT(
myseq,
mytp,
TP_ARGS(
uint64_t *, values_arg,
unsigned int, len_arg,
uint32_t, marker_arg
),
TP_FIELDS(
ctf_sequence(uint64_t, values, values_arg, unsigned int, len_arg)
ctf_integer(uint32_t, marker, marker_arg)
)
)
</pre>
<p>The "marker" is used to find the traced data in a hexdump of the CTF files. The error also occurs when the marker field is left out.</p>
<p>This is a small application using the tracepoint to trace the integer values of its command line arguments usint the tracepoint:</p>
<pre>
#include <myseq.h>
#include <stdlib.h>
#include <stdint.h>
int main(int argc, char **argv) {
int i;
uint64_t values[argc - 1];
for (i = 1; i < argc; ++i) {
values[i - 1] = atoi(argv[i]);
}
tracepoint(myseq, mytp, values, argc - 1, 0x11223344);
return 0;
}
</pre>
<p>I use this script on <code>aarch64</code> to reproduce the error:</p>
<pre>
#! /bin/bash
set -eux -o pipefail
cd "$(dirname "$0")"
mkdir -p build
cd build
lttng-gen-tp ../myseq.tp -o myseq.c -o myseq.h
gcc -Wall -Wextra -Werror -I . -o myapp ../main.c myseq.c -llttng-ust -ldl
# avoid empty sequence -> works
lttng create mysession --output mysession
lttng enable-event -s mysession -u 'myseq:*'
lttng start mysession
./myapp 1 2 3
./myapp 1 2 3 4 5
lttng stop mysession
lttng destroy mysession
babeltrace mysession
# empty sequence -> breaks
lttng create mysession2 --output mysession2
lttng enable-event -s mysession2 -u 'myseq:*'
lttng start mysession2
./myapp 1 2 3
./myapp # empty sequence
./myapp 1 2 3 4 5
lttng stop mysession2
lttng destroy mysession2
babeltrace mysession2
</pre>
<p>The babeltrace command to dump the CTF data of <code>mysession2</code> produces an error in most executions:</p>
<pre>
[15:21:00.555952242] (+?.?????????) jetson-tx2-tb31 myseq:mytp: { cpu_id = 5 }, { _values_length = 3, values = [ [0] = 1, [1] = 2, [2] = 3 ], marker = 287454020 }
[15:21:00.569996583] (+0.014044341) jetson-tx2-tb31 myseq:mytp: { cpu_id = 0 }, { _values_length = 0, values = [ ], marker = 0 }
[error] Unexpected end of packet. Either the trace data stream is corrupted or metadata description does not match data layout.
[error] Reading event failed.
Error printing trace.
</pre>
<p>The error occurs in more than half of the experiments when running the LTTng tracing on <code>aarch64</code>. It does not matter if babeltrace is executed on <code>aarch64</code> or on <code>x86_64@with the trace data recorded on @aarch64</code>.</p>
<p>The error occurs with the following versions of babeltrace:</p>
<ul>
<li>babeltrace 1.5.5</li>
<li>babeltrace 1.5.8</li>
<li>babeltrace git 64b7b73406 (origin/stable-1.5, stable-1.5)</li>
<li>babeltrace git 6488b1761f (master, origin/master)</li>
</ul>
<p>For the babeltrace2 version, the output is as follows:</p>
<pre>
07-20 17:54:11.039 27615 27615 E PLUGIN/CTF/MSG-ITER set_current_event_class@msg-iter.c:1266 [auto-disc-source-ctf-fs] No event class with ID of event class ID to use in stream class: msg-it-addr=0x55844033a7a0, stream-class-id=0, event-class-id=13124, trace-class-addr=0x55844033fc60
07-20 17:54:11.039 27615 27615 E PLUGIN/CTF/MSG-ITER ctf_msg_iter_get_next_message@msg-iter.c:2883 [auto-disc-source-ctf-fs] Cannot handle state: msg-it-addr=0x55844033a7a0, state=AFTER_EVENT_HEADER
07-20 17:54:11.039 27615 27615 E PLUGIN/SRC.CTF.FS ctf_fs_iterator_next_one@fs.c:91 [auto-disc-source-ctf-fs] Failed to get next message from CTF message iterator.
07-20 17:54:11.039 27615 27615 W LIB/MSG-ITER bt_message_iterator_next@iterator.c:868 Component input port message iterator's "next" method failed: iter-addr=0x55844033a630, iter-upstream-comp-name="auto-disc-source-ctf-fs", iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE, iter-upstream-comp-class-name="fs", iter-upstream-comp-class-partial-descr="Read CTF traces from the file sy", iter-upstream-port-type=OUTPUT, iter-upstream-port-name="2a7e7597-25fb-4596-9f9e-cfaa07ad4dcf | 0 | 0", status=ERROR
07-20 17:54:11.039 27615 27615 E PLUGIN/FLT.UTILS.MUXER muxer_upstream_msg_iter_next@muxer.c:448 [muxer] Upstream iterator's next method returned an error: status=ERROR
07-20 17:54:11.039 27615 27615 E PLUGIN/FLT.UTILS.MUXER validate_muxer_upstream_msg_iters@muxer.c:994 [muxer] Cannot validate muxer's upstream message iterator wrapper: muxer-msg-iter-addr=0x558440339f60, muxer-upstream-msg-iter-wrap-addr=0x55844033ab70
[15:21:00.555952242] (+?.?????????) jetson-tx2-tb31 myseq:mytp: { cpu_id = 5 }, { _values_length = 3, values = [ [0] = 1, [1] = 2, [2] = 3 ], marker = 287454020 }
[15:21:00.569996583] (+0.014044341) jetson-tx2-tb31 myseq:mytp: { cpu_id = 0 }, { _values_length = 0, values = [ ], marker = 0 }
07-20 17:54:11.039 27615 27615 E PLUGIN/FLT.UTILS.MUXER muxer_msg_iter_next@muxer.c:1422 [muxer] Cannot get next message: comp-addr=0x558440338860, muxer-comp-addr=0x5584403429d0, muxer-msg-iter-addr=0x558440339f60, msg-iter-addr=0x558440339620, status=ERROR
07-20 17:54:11.039 27615 27615 W LIB/MSG-ITER bt_message_iterator_next@iterator.c:868 Component input port message iterator's "next" method failed: iter-addr=0x558440339620, 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
07-20 17:54:11.039 27615 27615 W LIB/GRAPH consume_graph_sink@graph.c:466 Component's "consume" method failed: status=ERROR, comp-addr=0x5584403389a0, 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=0, comp-class-so-handle-addr=0x55844031c450, comp-class-so-handle-path="/usr/local/stow/babeltrace2/lib/babeltrace2/plugins/babeltrace-plugin-text.la", comp-input-port-count=1, comp-output-port-count=0
07-20 17:54:11.039 27615 27615 E CLI cmd_run@babeltrace2.c:2530 Graph failed to complete successfully
ERROR: [Babeltrace CLI] (babeltrace2.c:2530)
Graph failed to complete successfully
CAUSED BY [libbabeltrace2] (graph.c:466)
Component's "consume" method failed: status=ERROR, comp-addr=0x5584403389a0,
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=0, comp-class-so-handle-addr=0x55844031c450,
comp-class-so-handle-path="/usr/local/stow/babeltrace2/lib/babeltrace2/plugins/babeltrace-plugin-text.la",
comp-input-port-count=1, comp-output-port-count=0
CAUSED BY [libbabeltrace2] (iterator.c:868)
Component input port message iterator's "next" method failed:
iter-addr=0x558440339620, 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
CAUSED BY [muxer: 'filter.utils.muxer'] (muxer.c:1422)
Cannot get next message: comp-addr=0x558440338860,
muxer-comp-addr=0x5584403429d0, muxer-msg-iter-addr=0x558440339f60,
msg-iter-addr=0x558440339620, status=ERROR
CAUSED BY [muxer: 'filter.utils.muxer'] (muxer.c:994)
Cannot validate muxer's upstream message iterator wrapper:
muxer-msg-iter-addr=0x558440339f60,
muxer-upstream-msg-iter-wrap-addr=0x55844033ab70
CAUSED BY [muxer: 'filter.utils.muxer'] (muxer.c:448)
Upstream iterator's next method returned an error: status=ERROR
CAUSED BY [libbabeltrace2] (iterator.c:868)
Component input port message iterator's "next" method failed:
iter-addr=0x55844033a630, iter-upstream-comp-name="auto-disc-source-ctf-fs",
iter-upstream-comp-log-level=WARNING, iter-upstream-comp-class-type=SOURCE,
iter-upstream-comp-class-name="fs",
iter-upstream-comp-class-partial-descr="Read CTF traces from the file sy",
iter-upstream-port-type=OUTPUT,
iter-upstream-port-name="2a7e7597-25fb-4596-9f9e-cfaa07ad4dcf | 0 | 0",
status=ERROR
CAUSED BY [auto-disc-source-ctf-fs (2a7e7597-25fb-4596-9f9e-cfaa07ad4dcf | 0 | 0): 'source.ctf.fs'] (fs.c:91)
Failed to get next message from CTF message iterator.
CAUSED BY [auto-disc-source-ctf-fs: 'source.ctf.fs'] (msg-iter.c:2883)
Cannot handle state: msg-it-addr=0x55844033a7a0, state=AFTER_EVENT_HEADER
CAUSED BY [auto-disc-source-ctf-fs: 'source.ctf.fs'] (msg-iter.c:1266)
No event class with ID of event class ID to use in stream class:
msg-it-addr=0x55844033a7a0, stream-class-id=0, event-class-id=13124,
trace-class-addr=0x55844033fc60
</pre>
<a name="Some-Ideas"></a>
<h2 >Some Ideas<a href="#Some-Ideas" class="wiki-anchor">¶</a></h2>
<p>I think the issue happens only if the length type of the sequence has a smaller alignment than the array element type of the sequence. <code>liblttng-ust</code> apparently aligns the offset of the begin of the (empty) sequence array to the expected array element alignment, even when writing no elements.</p>
<p>My current hypothesis is that babeltrace does not expect the array element alignment to happen when in case there are zero elements. However, I do not have any idea if this alignment should be there and babeltrace should expect it or if there should be no alignment in case of zero elements and liblttng-ust should not perform it.</p> LTTng-tools - Bug #1252 (Resolved): Session daemon's configuration file's format is not documente...https://bugs.lttng.org/issues/12522020-04-02T16:13:51ZPhilippe Proulxeeppeliteloop@gmail.comLTTng-tools - Bug #1251 (Resolved): Relay daemon's `--config` option is not documented in its man...https://bugs.lttng.org/issues/12512020-04-02T16:13:09ZPhilippe Proulxeeppeliteloop@gmail.comLTTng-tools - Bug #1011 (Resolved): lttng without any argument does not show help/usagehttps://bugs.lttng.org/issues/10112016-04-19T20:17:08ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Since the man page overhaul (2.8 and master), it appears that invoking lttng without any argument does not show a "usage" or help page.</p> LTTng-tools - Bug #1001 (Resolved): The configure script does not check liburcu's binary libraryhttps://bugs.lttng.org/issues/10012016-03-07T22:22:02ZPhilippe Proulxeeppeliteloop@gmail.com
<p>LTTng-tools's <code>configure.ac</code> only checks for liburcu function declarations in its installed headers using <code>AC_CHECK_DECL()</code>.</p>
<p>If, for some reason, the system has the headers installed, but not the binary library, the <code>configure</code> script succeeds, but the build fails later with obvious linking errors.</p>
<p>This situation happens if you set the various environment variables to build a 32-bit version of LTTng-tools (<code>CFLAGS</code>, <code>LDFLAGS</code> and so on) but only the 64-bit version of liburcu is installed. In this case, headers are found, for example in <code>/usr/include</code>, and <code>configure</code> succeeds, even if no 32-bit liburcu is installed.</p>
<p>It is okay to check the declarations, but <code>AC_CHECK_LIB()</code> should also be used to check the existence of the chosen symbols in an installed binary liburcu.</p>
<p>See <a href="https://github.com/lttng/lttng-ust/blob/master/configure.ac" class="external">LTTng-UST's <code>configure.ac</code></a> which seems to do the right thing.</p> LTTng-tools - Bug #998 (Resolved): UST and Java/Python log levels are not ordered the same wayhttps://bugs.lttng.org/issues/9982016-03-01T02:24:36ZPhilippe Proulxeeppeliteloop@gmail.com
<p>From <code>lttng enable-event --help</code>:</p>
<pre>
Available loglevels:
TRACE_EMERG = 0
TRACE_ALERT = 1
TRACE_CRIT = 2
TRACE_ERR = 3
TRACE_WARNING = 4
TRACE_NOTICE = 5
TRACE_INFO = 6
TRACE_DEBUG_SYSTEM = 7
TRACE_DEBUG_PROGRAM = 8
TRACE_DEBUG_PROCESS = 9
TRACE_DEBUG_MODULE = 10
TRACE_DEBUG_UNIT = 11
TRACE_DEBUG_FUNCTION = 12
TRACE_DEBUG_LINE = 13
TRACE_DEBUG = 14
(shortcuts such as "system" are allowed)
Available JUL domain loglevels:
JUL_OFF = INT32_MAX
JUL_SEVERE = 1000
JUL_WARNING = 900
JUL_INFO = 800
JUL_CONFIG = 700
JUL_FINE = 500
JUL_FINER = 400
JUL_FINEST = 300
JUL_ALL = INT32_MIN
(shortcuts such as "severe" are allowed)
Available LOG4j domain loglevels:
LOG4J_OFF = INT32_MAX
LOG4J_FATAL = 50000
LOG4J_ERROR = 40000
LOG4J_WARN = 30000
LOG4J_INFO = 20000
LOG4J_DEBUG = 10000
LOG4J_TRACE = 5000
LOG4J_ALL = INT32_MIN
(shortcuts such as "severe" are allowed)
Available Python domain loglevels:
PYTHON_CRITICAL = 50
PYTHON_ERROR = 40
PYTHON_WARNING = 30
PYTHON_INFO = 20
PYTHON_DEBUG = 10
PYTHON_NOTSET = 0
</pre>
<p>Notice how <code>TRACE_*</code> log levels are more severe when the numeric level is lower, and Java/Python log levels are more severe when the numeric level is higher.</p>
<p>The <code>--loglevel</code> option's help says:</p>
<pre>
Tracepoint loglevel range from 0 to loglevel.
</pre>
<p>Using this option with Java/Python events is not intuitive: if you specify <code>PYTHON_WARNING</code>, for example, you get events with log levels <code>PYTHON_NOTSET</code>, <code>PYTHON_DEBUG</code>, <code>PYTHON_INFO</code>, and <code>PYTHON_WARNING</code>, whereas you would normally expect to get <code>PYTHON_WARNING</code>, <code>PYTHON_ERROR</code>, and <code>PYTHON_CRITICAL</code> events.</p>
<p>I suggest the option's help is changed to something like:</p>
<pre>
--loglevel LOGLEVEL
Enable event if its log level is at least as severe as LOGLEVEL.
</pre>
<p>The code should be changed to check if the event's log level is in range:</p>
<ul>
<li><strong>[0, <code>LOGLEVEL</code>]</strong> for <code>TRACE_*</code> log levels (UST domain);</li>
<li><strong>[<code>LOGLEVEL</code>, infinity[</strong> for Java/Python/(future, I guess) log levels (agent domain).</li>
</ul> LTTng-tools - Bug #929 (Resolved): Can only disable one event amongst many agent events sharing t...https://bugs.lttng.org/issues/9292015-09-02T06:02:55ZPhilippe Proulxeeppeliteloop@gmail.com
<p>Enable at least two JUL/log4j/Python agent events sharing the same name:</p>
<pre>
lttng enable-event -j allo
lttng enable-event -j allo --loglevel JUL_INFO
</pre>
<p>List shows:</p>
<pre>
Events (Logger name):
---------------------
- allo [enabled] (loglevel <= JUL_INFO)
- allo [enabled]
</pre>
<p>Disable this event:</p>
<pre>
lttng disable-event -j allo
</pre>
<p>List shows:</p>
<pre>
Events (Logger name):
---------------------
- allo [disabled] (loglevel <= JUL_INFO)
- allo [enabled]
</pre> LTTng-tools - Bug #927 (Resolved): Multiple domain options are allowed in commands where it shoul...https://bugs.lttng.org/issues/9272015-09-01T23:10:26ZPhilippe Proulxeeppeliteloop@gmail.com
<p>In the <code>enable-channel</code>, <code>disable-channel</code>, <code>enable-event</code> and <code>disable-event</code> commands, it is possible to specify multiple domain options, and only one of them is actually used. The lucky domain to be elected seems to be the oldest one having been implemented in the great history of LTTng, i.e. the following precedence order applies: <code>-k</code>, <code>-u</code>, <code>-j</code>, <code>-l</code>, <code>-p</code>.</p>
<p>Examples:</p>
<pre>
$ lttng enable-channel -u -k allo
Kernel channel allo enabled for session a
</pre>
<pre>
$ lttng disable-channel -u -k allo
Kernel channel allo disabled for session a
</pre>
<pre>
$ lttng enable-channel -k -u allo
Kernel channel allo enabled for session a
</pre>
<pre>
$ lttng enable-event -u -j -p -k -l -c allo lol
Kernel event lol created in channel allo
</pre>
<pre>
$ lttng disable-event -p -l -u -j -c allo lol
UST event lol disabled in channel allo for session a
</pre>
<p>Smells like a switch-case.</p> LTTng-tools - Bug #917 (Resolved): Add track/untrack section in lttng(1) man pagehttps://bugs.lttng.org/issues/9172015-09-01T18:00:51ZJérémie Galarneaujeremie.galarneau@efficios.comLTTng-tools - Bug #913 (Resolved): Issuing both --loglevel and --loglevel-only for the same event...https://bugs.lttng.org/issues/9132015-08-29T04:16:44ZAnonymous
<p>If one enables an event for a given loglevel range (--loglevel), a subsequent enable for a specific loglevel (--loglevel-only) will not throw any error, but will have no effect.</p>
<p>For example:</p>
<pre>
lttng create
lttng enable-event -j myevent --loglevel warning
lttng enable-event -j myevent --loglevel-only warning
</pre>
<p><code>lttng list</code> will still only show:</p>
<pre>
Events (Logger name):
---------------------
- myevent [enabled] (loglevel <= JUL_WARNING)
</pre>
<p>It seems like a bug, as those are two different "event rules" and could be enabled side-by-side.</p>
<p>Note that if the two log levels are different (even if the conditions are "overlapping"), then it works correctly:</p>
<pre>
lttng create
lttng enable-event -j myevent --loglevel warning
lttng enable-event -j myevent --loglevel-only severe
</pre>
<p>lttng list then shows</p>
<pre>
Events (Logger name):
---------------------
- myevent [enabled] (loglevel == JUL_SEVERE)
- myevent [enabled] (loglevel <= JUL_WARNING)
</pre> LTTng-tools - Bug #908 (Resolved): Invalid free in list_ust_eventshttps://bugs.lttng.org/issues/9082015-08-25T02:09:00ZSimon Marchisimon.marchi@polymtl.ca
<p>If lttng_list_tracepoints fails (can't connect to a sessiond for example, I suppose), events_list is freed while not set. Here is the corresponding valgrind trace.</p>
<pre>
==5531== Memcheck, a memory error detector
==5531== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==5531== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==5531== Command: lttng list -u
==5531==
Error: Unable to list UST events: No session daemon is available
==5531== Conditional jump or move depends on uninitialised value(s)
==5531== at 0x4C2A611: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5531== by 0x40BE43: list_ust_events (list.c:548)
==5531== by 0x40BE43: cmd_list (list.c:1702)
==5531== by 0x408F03: handle_command (lttng.c:295)
==5531== by 0x408F03: parse_args (lttng.c:414)
==5531== by 0x408F03: main (lttng.c:464)
==5531==
==5531== Invalid free() / delete / delete[] / realloc()
==5531== at 0x4C2A65B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5531== by 0x40BE43: list_ust_events (list.c:548)
==5531== by 0x40BE43: cmd_list (list.c:1702)
==5531== by 0x408F03: handle_command (lttng.c:295)
==5531== by 0x408F03: parse_args (lttng.c:414)
==5531== by 0x408F03: main (lttng.c:464)
==5531== Address 0x401458 is not stack'd, malloc'd or (recently) free'd
==5531==
Error: Command error
==5531==
==5531== HEAP SUMMARY:
==5531== in use at exit: 0 bytes in 0 blocks
==5531== total heap usage: 45 allocs, 46 frees, 6,885 bytes allocated
==5531==
==5531== All heap blocks were freed -- no leaks are possible
==5531==
==5531== For counts of detected and suppressed errors, rerun with: -v
==5531== Use --track-origins=yes to see where uninitialised values come from
==5531== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
</pre> LTTng-tools - Feature #839 (Resolved): Split manpage of lttng commandhttps://bugs.lttng.org/issues/8392014-09-18T22:21:34ZPhilippe Proulxeeppeliteloop@gmail.com
<p>Since <code>lttng</code> has a Git like interface, following Git's one manpage per command would be nice.</p>
<p>Example:</p>
<pre>
man lttng-create
man lttng-list
man lttng-disable-event
</pre> LTTng-tools - Feature #836 (Resolved): List of events (lttng list) presents usability problemshttps://bugs.lttng.org/issues/8362014-09-11T19:28:02ZPhilippe Proulxeeppeliteloop@gmail.com
<p>Since events are effectively enabled/disabled using both the desired name and a specific filter, the list of events reported by <code>lttng list</code> is not always useful because it doesn't give details about the original filter.</p>
<p>Example:</p>
<pre>
lttng create test
lttng enable-event -u hello:world --filter 'field < 1'
lttng enable-event -u hello:world --filter 'field < 2'
lttng enable-event -u hello:world --filter 'field < 3'
lttng enable-event -u hello:world --filter 'field < 4'
lttng enable-event -u hello:world --filter 'field < 5'
lttng enable-event -u hello:world --filter 'field < 6'
lttng enable-event -u hello:world --filter 'field < 7'
lttng enable-event -u hello:world --filter 'field < 8'
lttng disable-event -u hello:world
lttng enable-event -u hello:world --filter 'field < 2'
lttng enable-event -u hello:world --filter 'field < 4'
lttng enable-event -u hello:world --filter 'field < 7'
lttng list test
</pre>
<p>Result:</p>
<pre>
Tracing session test: [inactive]
Trace path: /home/eepp/lttng-traces/test-20140911-144801
=== Domain: UST global ===
Buffer type: per UID
Channels:
-------------
- channel0: [enabled]
Attributes:
overwrite mode: 0
subbufers size: 131072
number of subbufers: 4
switch timer interval: 0
read timer interval: 0
trace file count: 0
trace file size (bytes): 0
output: mmap()
Events:
hello:world (type: tracepoint) [disabled] [with filter]
hello:world (type: tracepoint) [enabled] [with filter]
hello:world (type: tracepoint) [disabled] [with filter]
hello:world (type: tracepoint) [disabled] [with filter]
hello:world (type: tracepoint) [enabled] [with filter]
hello:world (type: tracepoint) [disabled] [with filter]
hello:world (type: tracepoint) [enabled] [with filter]
hello:world (type: tracepoint) [disabled] [with filter]
</pre>
<p>Suggested output (events section isolated):</p>
<pre>
Events:
hello:world (type: tracepoint) [disabled]
filter: "field < 1"
hello:world (type: tracepoint) [enabled]
filter: "field < 2"
hello:world (type: tracepoint) [disabled]
filter: "field < 3"
hello:world (type: tracepoint) [disabled]
filter: "field < 4"
hello:world (type: tracepoint) [enabled]
filter: "field < 5"
hello:world (type: tracepoint) [disabled]
filter: "field < 6"
hello:world (type: tracepoint) [enabled]
filter: "field < 7"
hello:world (type: tracepoint) [disabled]
filter: "field < 8"
</pre>
<p>Other suggestion:</p>
<pre>
Events:
1) hello:world (type: tracepoint) [disabled]
filter: "field < 1"
2) hello:world (type: tracepoint) [enabled]
filter: "field < 2"
3) hello:world (type: tracepoint) [disabled]
filter: "field < 3"
4) hello:world (type: tracepoint) [disabled]
filter: "field < 4"
5) hello:world (type: tracepoint) [enabled]
filter: "field < 5"
6) hello:world (type: tracepoint) [disabled]
filter: "field < 6"
7) hello:world (type: tracepoint) [enabled]
filter: "field < 7"
8) hello:world (type: tracepoint) [disabled]
filter: "field < 8"
</pre>
<p>If always ordered the same way, this could be possible:</p>
<pre>
lttng disable-event -u 5
lttng enable-event -u 4,6
</pre>
<p>Other idea:</p>
<pre>
lttng enable-event -u hello:world --filter 'field < 1' --alias bob
lttng enable-event -u hello:world --filter 'field < 2'
lttng enable-event -u hello:world --filter 'field < 3'
lttng enable-event -u hello:world --filter 'field < 4' --alias yeah
lttng enable-event -u hello:world --filter 'field < 5'
lttng enable-event -u hello:world --filter 'field < 6'
lttng enable-event -u hello:world --filter 'field < 7'
lttng enable-event -u hello:world --filter 'field < 8'
</pre>
<p>The list would look like:</p>
<pre>
Events:
1) hello:world (type: tracepoint) [disabled]
alias: bob
filter: "field < 1"
2) hello:world (type: tracepoint) [enabled]
filter: "field < 2"
3) hello:world (type: tracepoint) [disabled]
filter: "field < 3"
4) hello:world (type: tracepoint) [disabled]
alias: yeah
filter: "field < 4"
5) hello:world (type: tracepoint) [enabled]
alias: hello
filter: "field < 5"
6) hello:world (type: tracepoint) [disabled]
filter: "field < 6"
7) hello:world (type: tracepoint) [enabled]
filter: "field < 7"
8) hello:world (type: tracepoint) [disabled]
filter: "field < 8"
</pre>
<p>So that you can do:</p>
<pre>
lttng disable-event -u --alias bob
lttng enable-event -u --alias hello
lttng enable-event -u --alias bob
</pre> LTTng-tools - Bug #751 (Resolved): Channel names ought to be filtered just like session nameshttps://bugs.lttng.org/issues/7512014-03-07T17:21:01ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>Channel names obey the same limit (<code>NAME_MAX</code>) as session names, and since they have pretty much the same role storage-path-wise, they ought to be checked in the same way.</p>
<p>Right now, the only character one cannot include in a channel name is the comma, because the <code>enable-channel</code> command treats it as a channel name separator. Channel names may include spaces, but these need to be escaped in some contexts (e.g. 'lttng disable-channel -k my\ kernel\ channel').</p>
<p>However, it is perfectly legal to create a name like this:<br /><pre>
$ lttng enable-channel -k k/../ust/weird
</pre></p>
<p>This does not in fact create a misplaced kernel channel file: <em>it creates no file at all</em>, and no warning or error occurs. I haven't checked what happens if that channel is sent to a remote relay daemon, but that would undoubtedly be just as troublesome.</p>