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> Babeltrace - Bug #1374 (New): Babeltrace fails to read trace with no data stream type ID when the...https://bugs.lttng.org/issues/13742023-04-26T17:57:32ZErica Bugden
<p>Babeltrace is not able to read a trace that does not contain data stream IDs (empty packet header) when the metadata specifies an ID for the stream. Trace Compass is also unable to read this trace. If the lines mentioning the stream ID are removed from the metadata, then babeltrace is able to read the trace.</p>
<a name="Does-this-need-to-be-fixed"></a>
<h3 >Does this need to be fixed?<a href="#Does-this-need-to-be-fixed" class="wiki-anchor">¶</a></h3>
<p>This was first reported as a barectf issue <a class="external" href="https://github.com/efficios/barectf/issues/28">https://github.com/efficios/barectf/issues/28</a> , but after further consideration the issue appears to be in a grey area in the CTF 1.8 specification. Whether it is the CTF generator's (barectf) responsibility or the CTF reader's responsibility is up for debate.</p>
<p>The superfluous metadata information need not prevent the trace from being parsed. For example, yactfr <a class="external" href="https://github.com/eepp/yactfr">https://github.com/eepp/yactfr</a> is able to read the trace. However, considering that:</p>
<ul>
<li>At least two CTF readers (babeltrace and Trace Compass) cannot read the trace, and</li>
<li>It is easy to fix in barectf (Proposed fix: <a class="external" href="https://review.lttng.org/c/barectf/+/9868">https://review.lttng.org/c/barectf/+/9868</a> )</li>
</ul>
<p>this is not a high priority issue in babeltrace.</p>
<a name="Context"></a>
<h1 >Context<a href="#Context" class="wiki-anchor">¶</a></h1>
<p>- Background and reproducer: barectf github issue <a class="external" href="https://github.com/efficios/barectf/issues/28">https://github.com/efficios/barectf/issues/28</a> <br />- Background and specification discussion: barectf fix <a class="external" href="https://review.lttng.org/c/barectf/+/9868">https://review.lttng.org/c/barectf/+/9868</a></p> 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 #1267 (New): odr-violation for config_str_yeshttps://bugs.lttng.org/issues/12672020-05-13T01:16:50ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Using "clang version 10.0.0-4ubuntu1".</p>
<p>Configure: "./configure CFLAGS="-g -O0 -fsanitize=address"</p>
<p>lttng-sessiond yield:<br /><pre>
=================================================================
==3248430==ERROR: AddressSanitizer: odr-violation (0x000000800e80):
[1] size=8 'config_str_yes' session-config.c:56:20
[2] size=8 'config_str_yes' session-config.c:56:20
These globals were registered at these points:
[1]:
#0 0x43447d in __asan_register_globals (/home/joraj/lttng/master/install/bin/lttng-sessiond+0x43447d)
#1 0x6e6a8b in asan.module_ctor (/home/joraj/lttng/master/install/bin/lttng-sessiond+0x6e6a8b)
[2]:
#0 0x43447d in __asan_register_globals (/home/joraj/lttng/master/install/bin/lttng-sessiond+0x43447d)
#1 0x7eff93c40a6b in asan.module_ctor (/home/joraj/lttng/master//install/lib/liblttng-ctl.so.0+0x144a6b)
==3248430==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'config_str_yes' at session-config.c:56:20
==3248430==ABORTING
</pre></p>
<p>The linker does not warn.</p> LTTng-tools - Bug #1262 (New): Metadata channel properties are not configurable (kernel domain)https://bugs.lttng.org/issues/12622020-05-05T22:45:05ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>It is possible to explicitly create a kernel channel named <em>metadata</em> in the kernel domain.</p>
<pre>
$ lttng enable-channel -k metadata --num-subbuf 256
Kernel channel metadata enabled for session youssef_robert
</pre>
<p>This channel can be listed:<br /><pre>
- metadata: [enabled]
Attributes:
Event-loss mode: discard
Sub-buffer size: 1048576 bytes
Sub-buffer count: 256
Switch timer: inactive
Read timer: 200000 µs
Monitor timer: 1000000 µs
Blocking timeout: 0 µs
Trace file count: 1 per stream
Trace file size: unlimited
Output mode: splice
Statistics:
Discarded events: 0
Event rules:
None
</pre></p>
<p>It is surprisingly possible to add event rules to such a channel.</p>
<pre>
lttng enable-event -k -a -c metadata
All Kernel events are enabled in channel metadata
</pre>
<p>Predictably, since this channel is not identified as a <em>special</em> metadata channel, the configuration is not used during the <a href="https://github.com/lttng/lttng-tools/blob/ab5be9f/src/bin/lttng-sessiond/kernel-consumer.c#L203" class="external">creation of the metadata stream</a>.</p>
<p>Instead, a <a href="https://github.com/lttng/lttng-tools/blob/ab5be9fa2eb5ba9600a82cd18fd3cfcbac69169a/src/bin/lttng-sessiond/trace-kernel.h#L100" class="external">dedicated ltt_kernel_metadata</a> field is used. This field is initialized during the creation of the kernel session with a set of default attributes.</p>
<p>It is unclear to me if this ever worked since I couldn't find a trace of the code that should handle this.</p> LTTng-tools - Bug #1256 (New): Check babeltrace1 stderr output in testshttps://bugs.lttng.org/issues/12562020-04-08T19:23:18ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Currently, babeltrace1 stderr's output contains warnings which are not checked by the tests. Those do not fail the overall babeltrace execution, but end up being unexpected regressions when they appear between releases.</p>
<p>We could modify all babeltrace invocations to add a helper which saves the stderr output, and check that it is empty after babeltrace has completed execution. If non-empty, a test error would be reported.</p> Babeltrace - Bug #1234 (Feedback): src.text.dmesg: some kernel ring buffer lines can be wrongly s...https://bugs.lttng.org/issues/12342020-02-17T21:54:00ZPhilippe Proulxeeppeliteloop@gmail.com
<p>The lines of the <code>dmesg</code> command start with a time. The lines are supposed to be in order of time, but some of them can be at the wrong place.</p>
<p><code>flt.utils.muxer</code> does not like this and complains that event messages are not sorted by their default clock snapshot value.</p>
<p>It is, in fact, a <code>src.text.dmesg</code> bug because a message iterator must emit messages in order of time.</p>
<p>If the input is a file, one solution would be to sort the lines first (if not too large), and then emit the messages in this order.</p>
<p>We could also, in all scenarios, skip the lines with a time that is before the last event message's time and warn accordingly.</p> Babeltrace - Bug #1223 (Feedback): Check for cmp and diff in configurehttps://bugs.lttng.org/issues/12232020-02-17T21:03:26ZSimon Marchisimon.marchi@polymtl.ca
<p>Seen somewhere in the configure output of babeltrace on a fresh centos 8 container:</p>
<pre>
checking for a working dd... ./configure: line 9826: cmp: command not found
checking if gcc supports -fno-rtti -fno-exceptions... ./configure: line 11790: diff: command not found
</pre>
<p>The configure keeps going, I think the consequence may simply be that the results of these checks are inaccurate.</p>
<p>For correctness, if these tools (cmd and diff) are used, there should be something that checks that they exist before using them.</p> LTTng-tools - Bug #1211 (New): Can't quit lttng-sessiond with ctrl-c when built with --disable-epollhttps://bugs.lttng.org/issues/12112019-11-28T21:59:44ZSimon Marchisimon.marchi@polymtl.ca
<p>Step 1: configure lttng-tools with <code>./configure --disable-epoll</code><br />Step 2: launch lttng-sessiond<br />Step 3: try to stop it with ctrl-c</p>
<p>It should quit, but it doesn't quit.</p>
<p>My thorough investigation has shown that the "client management" thread stays in an infinite loop in compat_poll_wait.</p> LTTng-tools - Bug #1159 (Feedback): Missing documentation: before Linux 4.17, suspending the syst...https://bugs.lttng.org/issues/11592018-04-20T19:22:26ZPhilippe Proulxeeppeliteloop@gmail.com
<p>From LWN:</p>
<blockquote>
<p>The CLOCK_MONOTONIC and CLOCK_BOOTTIME clocks used to differ only in that the latter is fast-forwarded after a suspend-and-resume cycle. As of 4.17, CLOCK_MONOTONIC is also moved forward to reflect the time that the system spent suspended. As a result, the two timers are now identical and have been unified within the kernel. Among other things, that change eliminates a potentially surprising behavior wherein the offset between the monotonic and realtime clocks would change after a resume. Thomas Gleixner noted: "There might be side effects in applications, which rely on the (unfortunately) well documented behaviour of the MONOTONIC clock, but the downsides of the existing behaviour are probably worse.</p>
</blockquote>
<p>We should document that LTTng can produce incorrect traces when the target system is suspended while tracing is active if the system runs Linux 4.16 or less.</p>
<p>Mathieu Desnoyers suggested that we put this in <code>lttng-regenerate(1)</code>'s man page. Is this the appropriate location? Should the warning exist in all command man pages (as a common limitation at the end of the page)? <code>lttng-create(1)</code>'s man page could also be an appropriate location.</p> LTTng-tools - Bug #1124 (Feedback): lttng-sessiond saves empty domain stubshttps://bugs.lttng.org/issues/11242017-07-24T22:35:16ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>The save command, when used to save a session containing a single log4j event and channel, produces empty stubs for all userspace domains.</p>
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<sessions>
<session>
<name>test</name>
<domains>
<domain>
<type>UST</type>
<buffer_type>PER_UID</buffer_type>
<channels/>
<trackers/>
</domain>
<domain>
<type>JUL</type>
<buffer_type>PER_UID</buffer_type>
<channels/>
</domain>
<domain>
<type>LOG4J</type>
<buffer_type>PER_UID</buffer_type>
<channels>
<channel>
<name>lttng_log4j_channel</name>
<enabled>true</enabled>
<overwrite_mode>DISCARD</overwrite_mode>
<subbuffer_size>524288</subbuffer_size>
<subbuffer_count>4</subbuffer_count>
<switch_timer_interval>0</switch_timer_interval>
<read_timer_interval>0</read_timer_interval>
<output_type>MMAP</output_type>
<tracefile_size>0</tracefile_size>
<tracefile_count>0</tracefile_count>
<live_timer_interval>0</live_timer_interval>
<events>
<event>
<name>dfklasj</name>
<enabled>true</enabled>
<type>TRACEPOINT</type>
<loglevel_type>ALL</loglevel_type>
<filter>logger_name == &quot;dfklasj&quot;</filter>
</event>
</events>
<contexts/>
</channel>
</channels>
</domain>
<domain>
<type>PYTHON</type>
<buffer_type>PER_UID</buffer_type>
<channels/>
</domain>
</domains>
<started>false</started>
<output>
<consumer_output>
<enabled>true</enabled>
<destination>
<path>/home/jgalar/lttng-traces/test-20170724-142342</path>
</destination>
</consumer_output>
</output>
</session>
</sessions>
</pre>
<p>Reproduction steps:</p>
<pre>
$ lttng create test
Session test created.
Traces will be written in /home/jgalar/lttng-traces/test-20170724-142342
$ lttng enable-channel -u lttng_log4j_channel --monitor-timer 456789
UST channel lttng_log4j_channel enabled for session test
$ lttng enable-event -l dfklasj
LOG4J event dfklasj enabled
$ lttng list test
Tracing session test: [inactive]
Trace path: /home/jgalar/lttng-traces/test-20170724-142342
=== Domain: UST global ===
Buffer type: per UID
Channels:
-------------
- lttng_log4j_channel: [enabled]
Attributes:
overwrite mode: 0
subbuffers size: 524288
number of subbuffers: 4
switch timer interval: 0
read timer interval: 0
monitor timer interval: 456789
trace file count: 0
trace file size (bytes): 0
discarded events: 0
lost packets: 0
output: mmap()
Events:
None
=== Domain: LOG4j (Logging for Java) ===
Events (Logger name):
---------------------
- dfklasj [enabled] [filter: 'logger_name == "dfklasj"']
$ lttng save
All sessions have been saved successfully.
</pre> LTTng-UST - Bug #1109 (Feedback): Fork() test 9 from Linux Test Project fails when traced with us...https://bugs.lttng.org/issues/11092017-05-23T00:00:56ZRicardo Nabinger Sanchezrnsanchez@gmail.com
<p>While tracing <a href="https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/syscalls/fork" class="external"><code>fork09</code></a> test from <a href="https://github.com/linux-test-project/ltp" class="external">LTP</a>, the test failed unexpectedly. LTTng required some of the FDs the test aims at exhausting. It seems such a test will always fail when tracing, for it assumes it will be the sole user of its FD space.</p>
<p>LTTng-ust master as of <a class="changeset" title="Fix: Quote CMAKE variable assignment in Makefile Signed-off-by: Michael Jeanson <mjeanson@effici..." href="https://bugs.lttng.org/projects/lttng-ust/repository/lttng-ust/revisions/dd77bd5b20e95fefa8d857fdd3b7c9bdbbf24bc7">dd77bd5b20e95fefa8d857fdd3b7c9bdbbf24bc7</a>.</p>
<p>Steps to reproduce:<br /><pre>
git clone https://github.com/linux-test-project/ltp.git
cd ltp
make autotools
./configure
make
</pre></p>
<p>Then, when running as root, the test will abort if the problem is triggered:<br /><pre>
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 ./fork09
</pre></p>
<p>Example output:<br /><pre>
ltp/testcases/kernel/syscalls/fork# LD_PRELOAD=liblttng-ust-dl.so:liblttng-ust-fork.so:liblttng-ust-fd.so ./fork09
fork09 0 TINFO : OPEN_MAX is 1024
fork09 0 TINFO : first file descriptor is 22
fork09 0 TINFO : Parent reporting 1023 files open
fork09 0 TINFO : Child opened new file #1023
libgcc_s.so.1 must be installed for pthread_cancel to work
fork09 1 TBROK : tst_sig.c:233: unexpected signal SIGIOT/SIGABRT(6) received (pid = 2568).
fork09 2 TBROK : tst_sig.c:233: Remaining cases broken
fork09 0 TWARN : tst_tmpdir.c:337: tst_rmdir: rmobj(/tmp/forz9gzhZ) failed: unlink(/tmp/forz9gzhZ) failed; errno=21: EISDIR
fork09 1 TFAIL : fork09.c:147: test 1 FAILED
</pre></p>
<p>When checking the trace, one can see that some calls to <code>open()</code> failed with <code>errno == 24</code>, "Too many open files":<br /><pre>
...
[13:46:47.130018542] (+0.000013569) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/etc/ld.so.cache", flags = 524288, mode = 1 }
[13:46:47.130020273] (+0.000001731) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130021801] (+0.000001528) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/tls/x86_64/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130022801] (+0.000001000) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130023703] (+0.000000902) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64/tls/x86_64" }
[13:46:47.130026945] (+0.000003242) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = -2, statbuf = 140723106378272 }
[13:46:47.130027652] (+0.000000707) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/tls/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130028567] (+0.000000915) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130028952] (+0.000000385) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64/tls" }
[13:46:47.130030619] (+0.000001667) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = -2, statbuf = 140723106378272 }
[13:46:47.130031155] (+0.000000536) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/x86_64/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130032002] (+0.000000847) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130032395] (+0.000000393) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64/x86_64" }
[13:46:47.130034017] (+0.000001622) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = -2, statbuf = 140723106378272 }
[13:46:47.130034583] (+0.000000566) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/lib64/libgcc_s.so.1", flags = 524288, mode = 55440 }
[13:46:47.130035432] (+0.000000849) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130035793] (+0.000000361) rns syscall_entry_newstat: { cpu_id = 1 }, { filename = "/lib64" }
[13:46:47.130039354] (+0.000003561) rns syscall_exit_newstat: { cpu_id = 1 }, { ret = 0, statbuf = 140723106378272 }
[13:46:47.130045019] (+0.000005665) rns syscall_entry_open: { cpu_id = 1 }, { filename = "/dev/tty", flags = 2306, mode = 0 }
[13:46:47.130046134] (+0.000001115) rns syscall_exit_open: { cpu_id = 1 }, { ret = -24 }
[13:46:47.130046973] (+0.000000839) rns syscall_entry_writev: { cpu_id = 1 }, { fd = 2, vec = 140723106380368, vlen = 1 }
[13:46:47.130060399] (+0.000013426) rns syscall_exit_writev: { cpu_id = 1 }, { ret = 59, vec = 140723106380368 }
[13:46:47.130061293] (+0.000000894) rns syscall_entry_mmap: { cpu_id = 1 }, { addr = 0x0, len = 4096, prot = 3, flags = 34, fd = -1, offset = 0 }
[13:46:47.130067022] (+0.000005729) rns syscall_exit_mmap: { cpu_id = 1 }, { ret = 0x7FB33758B000 }
[13:46:47.130075155] (+0.000008133) rns syscall_entry_rt_sigprocmask: { cpu_id = 1 }, { how = 1, nset = 140723106380064, sigsetsize = 8 }
[13:46:47.130075728] (+0.000000573) rns syscall_exit_rt_sigprocmask: { cpu_id = 1 }, { ret = 0, oset = 0 }
[13:46:47.130126316] (+0.000050588) rns syscall_entry_rt_sigprocmask: { cpu_id = 1 }, { how = 0, nset = 140723106379920, sigsetsize = 8 }
[13:46:47.130128042] (+0.000001726) rns syscall_exit_rt_sigprocmask: { cpu_id = 1 }, { ret = 0, oset = 140723106379792 }
[13:46:47.130128816] (+0.000000774) rns syscall_entry_getpid: { cpu_id = 1 }, { }
[13:46:47.130129698] (+0.000000882) rns syscall_exit_getpid: { cpu_id = 1 }, { ret = 2568 }
[13:46:47.130130243] (+0.000000545) rns syscall_entry_gettid: { cpu_id = 1 }, { }
[13:46:47.130131252] (+0.000001009) rns syscall_exit_gettid: { cpu_id = 1 }, { ret = 2568 }
[13:46:47.130132261] (+0.000001009) rns syscall_entry_tgkill: { cpu_id = 1 }, { tgid = 2568, pid = 2568, sig = 6 }
</pre></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> LTTng - Bug #1060 (Confirmed): Document the extra reading subbuffer always allocatedhttps://bugs.lttng.org/issues/10602016-08-30T14:04:00ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>On channel creation a user might only consider the size of the passed argument instead we should either warn or document that there is always an extra sub buffer allocated for reading purpose.</p>
<p>See lib_ring_buffer_backend_allocate on lttng-modules.</p>
<p>This also apply to userspace.</p> LTTng-tools - Bug #822 (Confirmed): bash-completion sometimes completes too muchhttps://bugs.lttng.org/issues/8222014-07-28T18:04:17ZSimon Marchisimon.marchi@polymtl.ca
<p>I am not sure how to word it, but here is an example. I have a single session, named "auto-20140728-134322".</p>
<p>$ lttng des<tab> => $ lttng destroy</p>
<p>That's good, now let's press tab again:</p>
<p>$ lttng destroy <tab> => $ lttng destroy auto-20140728-134322</p>
<p>That's good, now let's press tab again:</p>
<p>$ lttng destroy auto-20140728-134322 <tab> => $ lttng destroy auto-20140728-134322 auto-20140728-134322</p>
<p>Oops, we can go like that for a long time. Every <tab> press adds a "auto-20140728-134322". It should detect that we already gave a positional argument. Since the command takes only one positional argument, subsequent <tab> presses should do nothing.</p>