LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912019-06-17T17:02:35ZLTTng bugs repository
Redmine LTTng-tools - Bug #1188 (Resolved): Error running "lttng list" when no sessions are availablehttps://bugs.lttng.org/issues/11882019-06-17T17:02:35ZGeneviève Bastiengbastien+lttng@versatic.net
<p>This bug applies to master and stable-2.11</p>
<p>When there are no tracing sessions, simply running `lttng list` gives the following result:</p>
<p>Error: Fatal error of the session daemon</p>
<p>while this should be expected</p>
<p>Currently no available tracing session</p>
<p>Bisecting shows this commit introduced the regression: b178f53e90c376dd44b020535c32649edef8f80e</p>
<p>Some debugging shows the problem is in the lttng_list_sessions (lttng-ctl.c) function, where the return value of lttng_ctl_ask_sessiond is 0 when no session is available and that 0 is converted to a fatal error instead of simply being returned as a count of 0 session.</p> LTTng-UST - Bug #1156 (Resolved): Redeclaration of rcu symbols when adding UST tracepoints to toolshttps://bugs.lttng.org/issues/11562018-02-26T19:58:14ZGeneviève Bastiengbastien+lttng@versatic.net
<p>As discussed offline, I am adding a monitoring thread to lttng-tools that monitors udev events and adds a lttng-ust event when <something> happens.</p>
<p>When trying to compile with lttng-ust tracepoints, I get compilation errors about redeclarations of rcu-related symbols defined in urcu-bp.h, included by ust includes and urcu.h included by tools, as the following output shows:</p>
<p>In file included from /usr/local/include/urcu-bp.h:62:0,<br /> from /usr/local/include/lttng/tracepoint-rcu.h:30,<br /> from /usr/local/include/lttng/tracepoint.h:29,<br /> from udev-monitor-provider.h:36,<br /> from udev-monitor.c:37:<br />/usr/local/include/urcu/static/urcu-bp.h:57:6: error: nested redefinition of ‘enum rcu_state’<br /> enum rcu_state {<br /> ^<sub>~~</sub>~~~~<br />/usr/local/include/urcu/static/urcu-bp.h:57:6: error: redeclaration of ‘enum rcu_state’<br />In file included from /usr/local/include/urcu.h:59:0,<br /> from lttng-sessiond.h:22,<br /> from udev-monitor.c:26:<br />/usr/local/include/urcu/static/urcu.h:77:6: note: originally defined here<br /> enum rcu_state {<br /> ^<sub>~~</sub>~~~~<br />In file included from /usr/local/include/urcu-bp.h:62:0,<br /> from /usr/local/include/lttng/tracepoint-rcu.h:30,<br /> from /usr/local/include/lttng/tracepoint.h:29,<br /> from udev-monitor-provider.h:36,<br /> from udev-monitor.c:37:<br />/usr/local/include/urcu/static/urcu-bp.h:58:2: error: redeclaration of enumerator ‘RCU_READER_ACTIVE_CURRENT’<br /> RCU_READER_ACTIVE_CURRENT,<br /> ^<sub>~~</sub>~~~~~~~~~~~~~~~~~~~~<br />In file included from /usr/local/include/urcu.h:59:0,<br /> from lttng-sessiond.h:22,<br /> from udev-monitor.c:26:<br />/usr/local/include/urcu/static/urcu.h:78:2: note: previous definition of ‘RCU_READER_ACTIVE_CURRENT’ was here<br /> RCU_READER_ACTIVE_CURRENT,<br /> ^<sub>~~</sub>~~~~~~~~~~~~~~~~~~~~</p> Babeltrace - Bug #1129 (Invalid): ctf writer: the timestamp value's monotonicity is validated glo...https://bugs.lttng.org/issues/11292017-08-03T22:54:57ZGeneviève Bastiengbastien+lttng@versatic.net
<p>I'm using babeltrace python bindings to write a CTF trace. My event is taken in an ebpf program where the timestamp is set, then sent to userspace via a perf buffer and then processed (written to ctf).</p>
<p>My events are monotonic in a stream (cpu). But it may happen that events from another stream with later timestamps are written before my current event, so they are not globally monotonic.</p>
<p>In the CTF writer (clock.c, method bt_ctf_clock_set_time), the timestamps are validated for monotonicity globally, so that my event raises an error and is not written.</p> LTTng - Bug #840 (Resolved): testhttps://bugs.lttng.org/issues/8402014-09-19T16:39:16ZGeneviève Bastiengbastien+lttng@versatic.net
<p>test bug</p> LTTng-modules - Feature #564 (Resolved): Add extra data to net_* tracepointshttps://bugs.lttng.org/issues/5642013-06-18T15:28:11ZGeneviève Bastiengbastien+lttng@versatic.net
<p>net_* kernel tracepoints have been added to lttng-modules recently, but with only basic data (address of skb, name).</p>
<p>It would be useful to have more information on those tracepoints, to be able to match data packets from different traces, etc.</p>
<p>Patch has been provided for it. See mailing list, patch from 04/24/2013</p> LTTng-modules - Feature #563 (Resolved): Support other CTF metadata: struct, enum, variantshttps://bugs.lttng.org/issues/5632013-06-18T15:25:26ZGeneviève Bastiengbastien+lttng@versatic.net
<p>CTF has metadata for struct, enum and variants but it is not possible to use those in tracepoints in lttng-modules.</p>
<p>Patches have been provided for it. See mailing list, patches from 04/24/2013</p> LTTng-modules - Bug #559 (Resolved): Lttng modules makes kernel crash on kernel 3.9.4https://bugs.lttng.org/issues/5592013-06-05T20:08:16ZGeneviève Bastiengbastien+lttng@versatic.net
<p>Using lttng_modules master or 2.2-rc2, enabling all events, starting a session. The kernel totally freezes.</p>
<p>Some crash report<br /><a class="external" href="http://i.imgur.com/ftm3ias.jpg">http://i.imgur.com/ftm3ias.jpg</a> from jgalar<br /><a class="external" href="http://imgur.com/jGASuQ7">http://imgur.com/jGASuQ7</a> from tahini</p> Babeltrace - Bug #490 (Resolved): Error opening metadata file from lttng kernel trace after modif...https://bugs.lttng.org/issues/4902013-03-28T17:33:27ZGeneviève Bastiengbastien+lttng@versatic.net
<p>I generated an lttng kernel trace and read it with babeltrace. I then modified the metadata file manually (to test new metadata structure for this trace) in a text editor, removing all binary characters and adding the /* CTF 1.8 */ header at the top. Babeltrace doesn't read it anymore and is not very verbose as to why. Java reader and TMF reads it fine.</p>
<p>Attached is the erroneous trace with modified metadata</p>