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 #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 - Feature #1287 (New): Use abstract sockets for lttng-consumerd UST shared memory fileshttps://bugs.lttng.org/issues/12872020-10-13T15:35:32ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Abstract sockets (unix(7)) are not tied to the filesystem, and are available since Linux 2.2.</p>
<p>Those are Linux-specific.</p>
<p>Those are the same as regular unix domain but their first character of path is NULL. They have the benefit of not requiring unlinking of files left behind.</p>
<p>We could use those abstract sockets in lttng-consumerd on Linux.</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 #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-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-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> LTTng-tools - Bug #752 (In Progress): Output paths need better handling than truncationhttps://bugs.lttng.org/issues/7522014-03-07T21:33:50ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
For instance, in the aftermath of <code>lttng-tools/src/bin/lttng-sessiond/cmd.c:record_ust_snapshot</code>, the <code>msg.u.snapshot_channel.pathname</code> is limited to PATH_MAX (typically 4096) but is built with <code>"%s/%s-%s-%" PRIu64 "%s"</code>, where the successive arguments are (discounting the closing nulls):
<ul>
<li><code>output->consumer->dst.trace_path</code> PATH_MAX - 1 (no trailing /)</li>
<li>/ 1</li>
<li><code>output->name</code> NAME_MAX - 1</li>
<li>- 1</li>
<li><code>output->datetime</code> 15</li>
<li>- 1</li>
<li><code>output->nb_snapshot</code> 20 digits (unsigned 64-bit integer)</li>
<li><code>session_path</code> PATH_MAX - 1 (including leading and trailing /)</li>
</ul>
<p>The worst-case <code>session_path</code> part is <code>'/ust/pid/<proc>-<vpid>-<datetime>/'</code> so it's actually limited to 12+15+5+15 = 47 characters (<code>/proc/PID/status.name</code> is truncated to 15 characters, and VPID is unsigned 16-bit for 5 characters) (closing null excluded). So one solution would be to limit the <code>consumer->dst.trace_path</code> to PATH_MAX - (NAME_MAX - 1 + 15 + 20 + 47 + 3) - 1 (for the null). However, if we want the path+filetitles of the channel files to fit in PATH_MAX, we need to chop another NAME_MAX off (and also limit channel names to NAME_MAX - (1 + 5 + 1 + 10 + 1) [underscore, 16-bit unsigned CPU ID, underscore, 32-bit unsigned chunk number, null] so they fit).</p>
<p>Truncation remains nevertheless possible, and would wreak havoc with the trace output tree. <code>Babeltrace</code> and the user count on proper folder and file tree structure to manage their traces. The code needs to detect instances of truncation and report them as errors.</p>
<p>As an aside, the snapshot output name should be limited to MAX_PATH - (1+10) because it gets suffixed with a hyphen and an unsigned 32-bit integer (the output set sequential ID).</p> LTTng-UST - Feature #717 (New): Better validation of tracepoint provider headers?https://bugs.lttng.org/issues/7172014-01-15T17:35:27ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>I fooled around to try and break the LTTng tracepoint provider preparation process at the level of the event field names. Turns out the literals supplied to the <code>ctf_*</code> macros as arguments for <code>TP_FIELDS</code> are pretty robust. Maybe too robust.</p>
<p>If you supply a non-identifier (see ISO/IEC 9899:TC2 (9899:1999) at 6.4.2 and Annex D) such as for instance "<code>named name</code>" or "<code>.name</code>", the tracepoint provider header compiles, links and packages into an <code>.so</code> without a hitch. The instrumented application likewise. Tracing also works flawlessly, producing a trace on disk. But when <code>babeltrace</code> tries to read it, it complains and gives up, with messages like:</p>
<pre>
[error] at line 110: token "name": syntax error, unexpected IDENTIFIER, expecting SEMICOLON or COMMA
[...]
</pre>
<p>(for "<code>named name</code>") or</p>
<pre>
[error] at line 110: token ".": syntax error, unexpected DOT, expecting SEMICOLON or COMMA
[...]
</pre>
<p>(for "<code>.name</code>")</p>
<p>There isn't much that can be done to prevent this. I would recommend merely amending the tracepoint provider samples slightly, like this:</p>
<pre>
/*
* The ctf_string macro takes a C string and writes it into a field
* named "message" (any C identifier will do for the field name)
*/
ctf_string(message, text)
</pre> LTTngTop - Feature #713 (New): Throughput display should be harmonized with lttng usagehttps://bugs.lttng.org/issues/7132014-01-13T14:44:35ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>The <code>lttngtop</code> starting window's statistics include a throughput display (generated in <code>src/cursesdisplay.c</code>), which is typically something like:<br /><pre>
FDs 2011 (+12,-13) 9KB/sec
</pre><br />It uses K, M and G to mean 1000, 10E6 and 10E9 respectively. Meanwhile, <code>lttng</code> uses the same letters in the <code>enable-channel</code> and <code>snapshot</code> commands (with the <code>subbuf-size</code>/<code>tracefile-size</code> and <code>max-size</code> options, respectively) to mean 1024, 1024^2 and 1024^3. The change of scale makes sense since the natural scale for throughput is metric while that for memory size is binary. The <code>lttng</code> command should ideally use the proper binary symbols (Ki, Mi, Gi), but that would make parsing the command option's value more difficult, so the exception is acceptable as long as the usage is properly documented.</p>
<p>My suggestion boils down to just two small corrections:</p>
<ul>
<li>The correct metric symbol 'k' should be used instead of 'K' (which can only mean kelvin or kibi).</li>
<li>A space should appear between the throughput value and its units.</li>
</ul> LTTng-UST - Bug #525 (Confirmed): new "notifications" from UST do not strictly respect LTTNG_UST_...https://bugs.lttng.org/issues/5252013-05-07T15:25:54ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We should eventually find a way to improve notifications from UST to sessiond so they don't delay .so loading (and thus application startup) when env. var. specify a LTTNG_UST_REGISTER_TIMEOUT=0. Currently, we work around this issue by setting the notification socket with a timeout of 100ms as minimum timeout if the LTTNG_UST_REGISTER_TIMEOUT value is below 100.</p>
<p>A cleaner fix could involve handling these notifications from a (possibly new) separate thread, and use a semaphore-based scheme to handle optional wait from the application.</p> LTTng-UST - Bug #292 (Confirmed): Generated header files should not conflict with ust or standard...https://bugs.lttng.org/issues/2922012-07-03T18:27:18ZMatthew Khouzam
<p>In Lttng-UST 2.0 if a given tracepoint file (foo.tp) has tracepint_events with domains that are not "foo" the tracepoint will not compile. This would be good to have a warning/error for, since if you don't it will just cause errors in the compilation phase which are <em>very</em> difficult to understand.</p> LTTng-UST - Feature #65 (New): Helper script to generate the tracepoint shared libraryhttps://bugs.lttng.org/issues/652012-02-17T20:15:25ZAnonymous
<p>By default, the compiled probes live in a shared library separate from the main binary.</p>
<p>Extend the helper script of <a class="issue tracker-2 status-5 priority-3 priority-lowest closed behind-schedule" title="Feature: Helper script to generate the tracepoint library (Resolved)" href="https://bugs.lttng.org/issues/40">#40</a> to compile and load this library automatically, and potentially offer an option to link it statically with the binary.</p> LTTng-UST - Feature #51 (New): lttng-gen-tp: add python module output https://bugs.lttng.org/issues/512012-02-16T15:25:43ZYannick Brosseauyannick.brosseau@polymtl.ca