LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912012-07-03T18:27:18ZLTTng bugs repository
Redmine 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-tools - Feature #286 (Confirmed): Add a --logfile option (or log through Syslog)https://bugs.lttng.org/issues/2862012-06-21T22:21:15ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>When we start lttng-sessiond in deamon mode, there is no way to get the verbose log.</p>
<p>having an option to log to a file and to syslog would be nice to debug deamon cases.</p> LTTng-tools - Feature #270 (Confirmed): Be able to choose session by number in lttng list commandhttps://bugs.lttng.org/issues/2702012-06-18T18:31:05ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>When we list the session with lttng list we get a list prefixed by number</p>
<blockquote>
<p>Available tracing sessions:<br />1) test (/home/scientist/lttng-traces/test-20120618-142554) [inactive]</p>
</blockquote>
<p>It seems natural after that to use this number when we want to have the detail of a session</p>
<blockquote>
<p>lttng list 1</p>
</blockquote>
<p>instead of doing lttng list test</p>
<p>(Its particularly painfull with the auto generated names.</p> Common Trace Format - Bug #265 (New): Specify where exactly the event ID must be in the headerhttps://bugs.lttng.org/issues/2652012-06-15T15:43:02ZPhilippe Proulxeeppeliteloop@gmail.com
<p>Here's how to read an event, having already parsed the metadata:</p>
<ol>
<li>read the event header (this is defined per-stream)</li>
<li><strong>find the ID</strong></li>
<li>find the event declaration for that ID</li>
<li>read the binary event according to its declaration</li>
</ol>
<p>Problem lies in step 2. There's no definition in the specs. regarding how to find the ID field within the event header. It cannot be as simple as finding the <code>id</code> field in the event header declaration since it can be elsewhere.</p>
<p>A good example is the LTTng event header declaration, which are often:</p>
<pre>
struct event_header_large {
enum : uint16_t { compact = 0 ... 65534, extended = 65535 } id;
variant <id> {
struct {
uint32_clock_monotonic_t timestamp;
} compact;
struct {
uint32_t id;
uint64_clock_monotonic_t timestamp;
} extended;
} v;
} align(8);
</pre>
<p>Here, <code>id</code> is most of the time the actual ID, but sometimes it's 65535 in order to extend the header using the variant and <code>v.extended.id</code> is the real ID. This is not specified in the specs.</p>
<p>We need a way to know (in the metadata) where is the real ID and how to know it once we read the header (between steps 1 and 2).</p> Common Trace Format - Bug #262 (New): Be clearer about fields of headers and contextshttps://bugs.lttng.org/issues/2622012-06-08T19:21:17ZPhilippe Proulxeeppeliteloop@gmail.com
<p>I've read the CTF specs. for hours by now and I still think there's something wrong about it. It seems like there's a division between some structure fields and their descriptions. Instead of clearly describing fields of some structures, only examples are given. But how are the examples related to the descriptions?</p>
<p>I would really appreciate that all fields of the following structures be very well defined in the specs.:</p>
<ul>
<li><code>trace.packet.header</code></li>
<li><code>stream.packet.context</code></li>
<li><code>stream.event.header</code></li>
</ul>
<p>This is actually done, but we don't see the relation between the field names and their descriptions.</p>
<p>Here's an example. The list following <em>Event packet context (all fields are optional, specified by TSDL meta-data):</em> is okay, but look at <em>Event packet content size (in bits).</em>: we don't know anything about this field yet. It's only later in the text that we learn:</p>
<pre>
If the content
size field is missing, the packet is filled (no padding). The content
and packet sizes include all headers.
</pre>
<p>Still, it's only when looking at the <em>example</em> that we see its name:</p>
<pre>
struct event_packet_context {
uint64_t timestamp_begin;
uint64_t timestamp_end;
uint32_t checksum;
uint32_t stream_packet_count;
uint32_t events_discarded;
uint32_t cpu_id;
uint32_t/uint16_t content_size;
uint32_t/uint16_t packet_size;
uint8_t compression_scheme;
uint8_t encryption_scheme;
uint8_t checksum_scheme;
};
</pre>
<p>But an example isn't very formal, is it? So if I want to know something about this field, I have to look at 3 different places in the specs.</p>
<p>And what about the <code>cpu_id</code> field in there? Is this LTTng-related or standard within CTF? I guess <em>this one</em> is really an example, but it's confusing because we learn the content size field name at the same place.</p>
<p>A good and easy format to understand/read would be a table, for each aforementioned structure, with the following columns:</p>
<ul>
<li>optional/mandatory/conditional?</li>
<li>absence of field meaning: what exactly to expect if the field is absent?</li>
<li>conditions if field is conditional (depends on other parameters)</li>
<li>field name (e.g. <code>content_size</code>)</li>
<li>complete description</li>
</ul>
<p>Maybe a <em>since version</em> column would also be great, so we may have some backward compatibility.</p>
<p>Also: for each <strong>structure</strong>, is it allowed to add custom fields?</p> Common Trace Format - Bug #254 (New): No specified charset for metadata packets payloadhttps://bugs.lttng.org/issues/2542012-06-05T21:19:18ZPhilippe Proulxeeppeliteloop@gmail.com
<p>There's no current specified charset for the metadata packets payload. This can be problematic because if a tracer makes this Unicode and we read it thinking it's ASCII, the displayed text will be weird and the reading could even break.</p>
Possible solutions are:
<ul>
<li>lock it in the specifications</li>
</ul>
<blockquote>
<ul>
<li>UTF-8: ASCII-compatible, so this shouldn't make a big difference for most cases but allows for i18n of event names and so on</li>
<li>ASCII: simple, but only English</li>
<li>avoid everything else IMO</li>
</ul>
</blockquote>
<ul>
<li>add a charset byte within the metadata packet header (e.g. 0 => ASCII, 1 => UTF-8, etc.), but this breaks binary compatibility</li>
</ul> LTTng - Feature #211 (New): Environment varshttps://bugs.lttng.org/issues/2112012-04-12T16:44:18ZMatthew Khouzam
Hi, I think it would be an interesting items to put in the environment variables.
<ul>
<li>Session creation time. ( To be sure you're dealing with the right trace) </li>
<li>Session destruction time. </li>
<li>Cpuinfo ( to understand performance, if you're running a 386 or an i7, the latencies are different)</li>
<li>Amount of Ram ( could quickly explain swapping)</li>
<li>hw info </li>
<li>network info</li>
<li>hostname (oops tracing the wrong machine)</li>
</ul> LTTng-tools - Feature #193 (Feedback): Find a more intelligent heuristics for the FD reservationhttps://bugs.lttng.org/issues/1932012-03-20T20:12:48ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>We currently reserve 25% of FD in the session deamon.</p>
<p>We could compute a better estimation, especially if we have lots of FD authorized.</p> LTTng-tools - Feature #137 (Confirmed): No more tracing possible after consumerD dies (via kill c...https://bugs.lttng.org/issues/1372012-02-29T15:58:59ZTan le trantan.dung.le.tran@ericsson.com
<p>There are a couple of weird behavior after the consumerD got killed via "kill" command.</p>
<p>Commit used when this test got carried out:<br /> userspace-rcu : feb-08 fcf4348721903bed57027c7eb0ea13765895cd37<br /> lttng-ust : feb-23 (20:11) 64493e4fa019e9bdfe0d9c6a4738c9552f250f35<br /> lttng-tools : feb-24 (14:41) 6bf73bf53464ad309fcf7f02a4dc397d280b81f8<br /> babeltrace : feb-23 (13:59) 305c65e5d7156ae7936f07ad93dd45ac318b4ce2</p>
<p>Here is the sceanrio: <br />1)_ lttng-sessiond -vvv &<br />2)_ Run the instrumented app <br />3)_ lttng create feb29_ses1 -o /tmp/tdlt/feb29_ses1<br /> lttng enable-event the_tracepoint_name -u<br /> lttng start<br /> Note: There are a couple of printout, "TEST: lib_ring_buffer_reserve data_size..." <br /> Those printf lines have been added by Mathieu to troubleshoot<br /> Issue-24 yesterday.<br />4)_ ps -elf |grep ltt<br />5)_ kill <process ID of consumerD><br />6)_ ps -elf |grep ltt<br /> get: [lttng-consumerd] <defunct><br /> No new consumerD has been spawned<br />7)_ lttng stop<br />8)_ lttng start feb29_ses1 (start the session again with the hope that new<br /> consummerD will be spawned)<br /> Note: still no new consummerD</p>
<p>9)_ lttng stop<br />10)_ ls -lR /tmp/tdlt/feb29_ses1/ust/<br /> get: all files with 0 size</p>
<p>11)_ lttng destroy</p>
<p>12)_ lttng create feb29_ses2 -o /tmp/tdlt/feb29_ses2 (test if new session is effected by the<br /> fact that consumerD dies previously)</p>
<p>13)_ lttng enable-event tracepoint_name -s feb29_ses2 -u</p>
<pre><code>Note: This process hang. Can not get the prompt back from the terminal (from where<br /> this command is entered).</code></pre>
<pre><code>&lt;ctrl&gt;+&lt;z&gt;<br /> bg</code></pre>
<pre><code>ps -elf |grep ltt<br /> get: :<br /> [lttng-consumerd] &lt;defunct&gt;<br /> lttng enable-event .... (enable-event is hanging)<br /> lttng-consumerd --quiet -u .... (a new consumerD is spawned)<br /> :</code></pre>
<p>14)_ lttng start<br /> lttng stop<br /> ls -lR /tmp/tdlt/feb29_ses2/ust/<br /> get: no files being created for this session !</p>
<p>15)_ lttng enable-event a_new_tracepoint -s feb29_2 -u<br /> Note: this one is also hanging !</p>
<pre><code>&lt;ctrl&gt;+&lt;z&gt;<br /> bg<br /> ps -elf |grep ltt<br /> get: :<br /> [lttng-consumerd] &lt;defunct&gt;<br /> lttng enable-event .... (1st enable-event is hanging)<br /> lttng-consumerd --quiet -u .... (previous consumerD is spawned)<br /> lttng enable-event .... (2nd enable-event is hanging)<br /> lttng-consumerd --quiet -u .... (a new consumerD is spawned)<br /> :</code></pre>
<p>16)_ kill <process_id of sessiond><br /> ps -elf |grep ltt<br /> get: :<br /> [lttng-consumerd] <defunct><br /> lttng enable-event .... (1st enable-event is hanging)<br /> lttng-consumerd --quiet -u .... (previous consumerD is spawned)<br /> lttng enable-event .... (2nd enable-event is hanging)<br /> lttng-consumerd --quiet -u .... (previous consumerD is spawned)<br /> :</p>
<p>17)_ lttng-sessiond -vvv &</p>
<p>18)_ lttng list -u <br /> Get: no apps has been registered !<br /> That means the application that already ran (before the<br /> consumerD is killed), can no longer see the new sessionD.</p>
<pre><code>Therefore, no more tracing is possible !</code></pre>
<p>Please, find enclosed the logfile for the above steps.</p> LTTng-tools - Feature #106 (Confirmed): Missing context information in list commandhttps://bugs.lttng.org/issues/1062012-02-24T18:13:01ZBernd HufmannBernd.Hufmann@ericsson.com
<p>After adding a context to an event there is no way to retrieve the context information, i.e. lttng list <session name> doesn't show the context information. <br />I think, a general rule should be, that things that can be configured should be able to be retrieved.</p>
<p>I used commit aeb968923d1245f4cb2be1eed2ab7b8b5eb45cf8</p>
<p>Here is an example sequence. As you can see "lttng list my"-comand doesn't show the context information:</p>
<blockquote>
<p>lttng create my</p>
</blockquote>
<p>Session my created.</p>
<p>Traces will be written in /home/eedbhu/lttng-traces/my-20120224-130527</p>
<blockquote>
<p>lttng enable-event sched_switch -k</p>
</blockquote>
<p>kernel event sched_switch created in channel channel0</p>
<blockquote>
<p>lttng add-context -k -e sched_switch -t pid</p>
</blockquote>
<p>kernel context pid added to event sched_switch</p>
<blockquote>
<p>lttng list my</p>
</blockquote>
<p>Tracing session my: [inactive]<br /> Trace path: /home/eedbhu/lttng-traces/my-20120224-130527</p>
<p>=== Domain: Kernel ===</p>
<p>Channels:<br />-------------<br />- channel0: [enabled]</p>
<pre><code>Attributes:<br /> overwrite mode: 0<br /> subbufers size: 262144<br /> number of subbufers: 4<br /> switch timer interval: 0<br /> read timer interval: 200<br /> output: splice()</code></pre>
<pre><code>Events:<br /> sched_switch (loglevel: TRACE_EMERG (0)) (type: tracepoint) [enabled]</code></pre> LTTng-tools - Feature #77 (Confirmed): Create developper documentation for the LTTng "control" APIhttps://bugs.lttng.org/issues/772012-02-20T17:56:05ZYannick Brosseauyannick.brosseau@polymtl.ca
<p>Anyone seeing that and there is no comments indicating otherwise, please contribute!!! :)</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.caLTTng-tools - Feature #35 (Confirmed): Remote administrationhttps://bugs.lttng.org/issues/352012-02-12T01:11:02ZAnonymous
<p>Allow trace control on remote machines via the "lttng" command.</p>
<p>We can do some of this through SSH, but we'd like to be able to set up sessions and trace destinations remotely.</p> LTTng-tools - Feature #15 (Confirmed): LTTng simple tracehttps://bugs.lttng.org/issues/152012-02-10T19:24:14ZMatthew Khouzam
<p>Requesting a new command in lttng-tools<br />the name should be something like trace and the functionality should be similar to strace. <br />the syntax could be something like <br />lttng trace program_name program_args <br />let's say you instrumented ls, then lttng trace ls -l /dev would trace ls going through the directory. <br />The traces taken should be both kernel and UST unless otherwise specified. <br />The timestamps for user space and kernel space should be on the same base. (Offsets will make this unusable by most) <br />the command sequence internally could be as simple as <br />lttng create default_name; lttng enable-event -a -k ; lttng enable-event -a -u; lttng start; %program_name; lttng stop; lttng destroy; <br />If the person is not in the tracing group or root, the kernel trace should be unavailable with a warning. if the application is not instrumented, it should warn too. if the kernel and userspace tracer is not available, it should warn that too but still run.</p>
<p>These ideas are very open for discussion</p>