LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912022-03-01T20:27:38ZLTTng bugs repository
Redmine LTTng - Feature #1347 (New): Codename for 2.14https://bugs.lttng.org/issues/13472022-03-01T20:27:38ZMichael Jeansonmjeanson@efficios.com
<p>What should the codename of the LTTng 2.14 release be?</p>
<p>Must be a micro-brewed Quebec beer and start with a "O".</p> LTTng-tools - Bug #1318 (New): lttng-tools configured with --with-consumerd32-libdir --with-consu...https://bugs.lttng.org/issues/13182021-06-07T15:17:28ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>The lttng-tools project is configured as such:</p>
<pre>
./configure --with-consumerd32-libdir=/usr/local/lib32 --with-consumerd32-bin=/usr/local/lib32/lttng/libexec/lttng-consumerd
</pre>
<p>Config.h does include definition for consumerd32 bit<br /><pre>
/* Location of the 32-bit consumerd executable. */
#define CONFIG_CONSUMERD32_BIN "/usr/local/lib32/lttng/libexec/lttng-consumerd"
/* Search for consumerd 32-bit libraries in this location. */
#define CONFIG_CONSUMERD32_LIBDIR "/usr/local/lib32"
</pre></p>
<p>On start the sessiond ignore those paths:</p>
<pre>
DEBUG1 - 14:57:13.370775164 [113567/113567]: consumerd32 path: /home/vagrant/.lttng/ustconsumerd32
DEBUG1 - 14:57:13.370793022 [113567/113567]: consumerd32 bin path: Unknown
DEBUG1 - 14:57:13.370825408 [113567/113567]: consumerd32 lib dir: Unknown
</pre>
<p>The code does not use CONFIG_CONSUMERD32_BIN anywhere.</p>
<p>Commit e6142f2e647e83238b1e399b1264e8adb05409f9 seems to have removed the code that used CONFIG_CONSUMERD32_BIN without providing an equivalent.</p>
<pre>
commit e6142f2e647e83238b1e399b1264e8adb05409f9
Author: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Date: Thu Nov 9 17:46:54 2017 -0500
centralize sessiond config option handling
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
</pre>
<pre>
-static const char *consumerd32_bin = CONFIG_CONSUMERD32_BIN;
-static const char *consumerd64_bin = CONFIG_CONSUMERD64_BIN;
-static const char *consumerd32_libdir = CONFIG_CONSUMERD32_LIBDIR;
-static const char *consumerd64_libdir = CONFIG_CONSUMERD64_LIBDIR;
</pre>
<p>Using the command line works fine:<br /><pre>
lttng-sessiond -vvv --verbose-consumer --consumerd32-libdir=/usr/local/lib32 --consumerd32-path=/usr/local/lib32/lttng/libexec/lttng-consumerd
</pre></p>
<p>Not sure if we want to use the path provided by configure or simply change the documentation to indicate that the paths must be passed either via the env or on the command line.</p> LTTng - Bug #1305 (New): Kernel test hang https://bugs.lttng.org/issues/13052021-04-13T19:54:29ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>The stable 2.12 kernel test for snapshot hang and timeout:</p>
<pre>
# Test local kernel snapshots with small discard buffers
ok 33 - Create session wIlYlgBxrDYiYhCQ in no-output mode
ok 34 - Enable small discard channel snapchan for session wIlYlgBxrDYiYhCQ
ok 35 - Enable kernel syscall -a for session wIlYlgBxrDYiYhCQ on channel snapchan
ok 36 - Start tracing for session wIlYlgBxrDYiYhCQ
ok 37 - Added snapshot output file:///tmp/tmp.YQ8oTaPXHl
ok 38 - Snapshot recorded
# First line (1st snapshot): [19:42:21.079000064] (+?.?????????) linaro-server syscall_exit_clone: { cpu_id = 3 }, { ret = 0 }
Marking unfinished test run as failed
case: 2_kernel-tests
case_id: 1930082
commit_id: 352aca7ac22367a79ad817c23753317d7a8ec281
definition: lava
duration: 9939.86
result: fail
uuid: 37271_1.4.2.4.9
lava-test-shell timed out after 10651 seconds
end: 3.1 lava-test-shell (duration 02:57:31) [common]
case: lava-test-shell
case_id: 1930083
definition: lava
duration: 10651.01
extra: ...
level: 3.1
namespace: common
result: fail
lava-test-retry failed: 1 of 1 attempts. 'lava-test-shell timed out after 10651 seconds'
</pre>
<p>The job name : vm_tests_klinux-4.9.y_lstable-2.12</p>
<p>See attached file for complete job logs.</p> LTTng-tools - Feature #1137 (Confirmed): Version handshake for lttng-consumerd and lttng-sessiondhttps://bugs.lttng.org/issues/11372017-11-15T23:37:32ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
Scenario:
<ul>
<li>User installed both a 32bit and 64 bit version of lttng-tools 2.X.</li>
<li>User uses in script lttng-session --consumerd32-path= --consumerd64-path=</li>
<li>User update the 64bit version to lttng-tools 2.(X+1) without upgrading</li>
<li>User still uses it's script but with the lttng-sessiond bin from lttng-tools 2.(X+1)</li>
</ul>
<p>Currently the consumerd and sessiond do not exchange version information hence we end up with undefined behaviour.</p>
<p>The version numbering might be coupled with the version of lttng but it is most probably wiser to use a separate versioning.</p> LTTng-tools - Feature #1133 (New): Metadata regeneration does not have to be "destructive"https://bugs.lttng.org/issues/11332017-10-30T20:13:37ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Currently the metadata regeneration is a possibly "destructive" test, it is possible to test both kernel and ust without performing such destructive manipulation.</p>
<p>From Julien:</p>
<p>lttng start<br />lttng stop<br />echo "" to metadata file (empty it)<br />validate that babeltrace cannot read the trace (as expected)<br />lttng start<br />lttng regenerate metadata<br />lttng stop<br />validate that babeltrace is now able to read the trace.</p> LTTng-tools - Bug #1128 (Confirmed): Contexts can be added multiple times to a kernel channelhttps://bugs.lttng.org/issues/11282017-08-03T02:48:03ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>The session daemon checks for duplicate user space contexts being enabled on a user space channel (using trace_ust_match_context()). A similar check is missing for kernel channels, allowing users to add the same context multiple times.</p>
<p><em>Extract from a session profile demonstrating the problem:</em><br /><pre>
<domain>
<type>KERNEL</type>
<buffer_type>GLOBAL</buffer_type>
<channels>
<channel>
<name>lol</name>
<enabled>true</enabled>
<overwrite_mode>DISCARD</overwrite_mode>
<subbuffer_size>1048576</subbuffer_size>
<subbuffer_count>4</subbuffer_count>
<switch_timer_interval>0</switch_timer_interval>
<read_timer_interval>200000</read_timer_interval>
<output_type>SPLICE</output_type>
<tracefile_size>0</tracefile_size>
<tracefile_count>0</tracefile_count>
<live_timer_interval>4294967295</live_timer_interval>
<monitor_timer_interval>1000000</monitor_timer_interval>
<blocking_timeout>0</blocking_timeout>
<events/>
<contexts>
<context>
<type>PID</type>
</context>
<context>
<type>PID</type>
</context>
<context>
<type>PID</type>
</context>
<context>
<type>PID</type>
</context>
<context>
<type>PID</type>
</context>
<context>
<type>PID</type>
</context>
<context>
<type>PID</type>
</context>
</contexts>
</channel>
</channels>
<trackers/>
</domain>
</pre></p> LTTng-tools - Bug #1114 (New): Possible invalid discarded events counthttps://bugs.lttng.org/issues/11142017-06-01T18:54:32ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>From Issue <a class="issue tracker-1 status-8 priority-4 priority-default closed" title="Bug: Fork() test 12 from Linux Test Project fails when traced with userspace events; events are miscou... (Invalid)" href="https://bugs.lttng.org/issues/1110">#1110</a>:</p>
<pre>
Then, when running as root, the test will abort if the problem is triggered:
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 ./fork12
After forcibly stopping the test (^C), errors are reported and events could be miscounted when issuing lttng stop:
[warning] 9223372037047268318 events discarded, please refer to the documentation on channel configuration.
</pre>
<p>Possible source of problem is that a negative is returned somewhere. Either by kernel or ust trace.</p> LTTng-tools - Bug #1105 (New): The trigger API should warn the client when an unsupported conditi...https://bugs.lttng.org/issues/11052017-05-12T19:11:03ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Clients should be warned whenever they register a trigger that won't be evaluated. For the moment, the main use case is warning a client if a buffer usage condition is used and the lttng-modules version being used is older than 2.10.</p> LTTng-tools - Bug #1102 (In Progress): Trigger conditions are not evaluated on subscriptionhttps://bugs.lttng.org/issues/11022017-05-11T22:43:22ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>Trigger conditions are not evaluated on subscription of a client. In the case of buffer usage conditions, this provides no way for clients to know the current state of the buffers.</p> LTTng-tools - Bug #1092 (New): Channel switch timers don't seem to be honoredhttps://bugs.lttng.org/issues/10922017-03-15T00:31:18ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>This bug is not confirmed, but investigating the consumer's code (see <em>consumer-timer.c</em>), it appears that the <em>live</em> and <em>switch</em> timer concepts were merged at the introduction of the live feature.</p>
<p>However, now the switch timer only seems to apply to the metadata channel. This means that there is no way for the user to force a periodical subbuffer switch in order to ensure periodical data flushes.</p> LTTng - Bug #1034 (Confirmed): KPROBE & KREPROBE support for saved/loaded sessions is not workinghttps://bugs.lttng.org/issues/10342016-06-22T21:01:13ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<p>Reproduce:</p>
<p>lttng create<br />lttng enable-event -k --probe={a valid address from System.map}<br />lttng save<br />lttng load -i {the path to the previously save session}</p>
<p>Same for --function</p> LTTng-modules - Bug #938 (Confirmed): Enabling two events with same name but not the same event t...https://bugs.lttng.org/issues/9382015-09-15T17:10:43ZJonathan Rajotte Julienjonathan.rajotte-julien@efficios.com
<pre>
sudo lttng-sessiond -d
lttng create mysession
lttng enable-event --kernel kmem_kfree --probe sys_open+0xE
lttng enable-event --kernel kmem_kfree
lttng start
sleep 0.1
lttng stop
lttng view
</pre>
<p>Only the probe is considered when tracing. The metadata only shows the probe event.</p>
<p>This is a kernel tracer side problem (name as event key). A solution could be to prefix certain type of event on enable thus creating namespace e.g: probe_kmem_kfree.</p> LTTng - Bug #934 (Confirmed): Session in snapshot mode does not indicate a path when listedhttps://bugs.lttng.org/issues/9342015-09-06T03:23:30ZJérémie Galarneaujeremie.galarneau@efficios.com
<p>The LTTng client does not indicate the default snapshot output path when listing a snapshot session.<br />It should either omit the "Trace path:", or indicate the default snapshot output path.</p>
<pre>
$ lttng create snap --snapshot
Session snap created.
Default snapshot output set to: /home/jgalar/lttng-traces/snap-20150905-232023
Snapshot mode set. Every channel enabled for that session will be set in overwrite mode and mmap output.
$ lttng list snap
Tracing session snap: [inactive snapshot]
Trace path:
</pre> LTTng-tools - Bug #833 (Confirmed): memcpy of non-packed struct into packed struct (possible layo...https://bugs.lttng.org/issues/8332014-09-09T13:17:10ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>lttng-tools src/lib/lttng-ctl/lttng-ctl.c:</p>
<p>lttng_enable_event_with_exclusions()</p>
<p>memcpy(&lsm.u.enable.event, ev, sizeof(lsm.u.enable.event));</p>
<p>copy "ev" (non-packed) into a packed structure.</p>
<p>We should copy each field one by one (create a copy_event_to_event_packed() helper to do so).</p> LTTng-tools - Feature #749 (Confirmed): lttng list <session> should list the contexts added to ea...https://bugs.lttng.org/issues/7492014-03-07T16:36:19ZDaniel U. Thibaultdaniel.thibault@drdc-rddc.gc.ca
<p>It would be nice if the <code>lttng list <session></code> command listed the context currently added to each channel. Currently, it does not mention context at all.</p>