LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912012-10-02T21:37:23ZLTTng bugs repository
Redmine Babeltrace - Bug #360 (Resolved): intermediate representation is leakinghttps://bugs.lttng.org/issues/3602012-10-02T21:37:23ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We have a nice comment in</p>
<p>formats/ctf/metadata/ctf-visitor-generate-io-struct.c</p>
<p>/* TODO: missing metadata "destroy" (memory leak) */</p>
<p>This <em>should</em> be implemented before 1.0 final, especially given that we now expose an external API. It made sense to disregard memory allocation when babeltrace was a one-shot command line converter, but not anymore.</p>
<p>Thorough testing under valgrind is recommended.</p> LTTng-tools - Bug #355 (Resolved): PERROR: sendmsg: Socket operation on non-sockethttps://bugs.lttng.org/issues/3552012-09-26T01:14:51ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>lttng-sessiond running as user.</p>
<p>lttng create<br />lttng enable-event -u -a<br />lttng start</p>
<p>and then run:</p>
<p>for a in $(seq 1 1000); do ./demo-trace; done</p>
<p>gets us many:</p>
<p>PERROR: sendmsg: Socket operation on non-socket [in lttcomm_send_unix_sock() at unix.c:204]<br />PERROR: send consumer channel: Socket operation on non-socket [in consumer_send_channel() at consumer.c:473]</p>
<p>from possibly sessiond or consumerd.</p> LTTng-tools - Bug #352 (Resolved): metadata partly missing with large subbuffers and stress-testhttps://bugs.lttng.org/issues/3522012-09-25T12:25:12ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>08:19 < Compudj> dgoulet, cbab: fyi, with lttng-tools master, I just ran into <br /> an issue with incomplete metadata<br />08:20 < Compudj> dgoulet, cbab: I used a channel config of 2 subbuffers/512MB <br /> per subbuffer, tracing a ping flood on localhost, stopping <br /> tracing after I notice that I have 2 buffers written to disk <br /> by the consumer<br />08:20 < Compudj> dgoulet, cbab: with kernel tracing<br />08:20 < Compudj> dgoulet, cbab: this is probably related to the problems you <br /> are looking for. so it's another way to reproduce it I guess.<br />08:21 < Compudj> dgoulet, cbab: or it could very well be a different issue.<br />08:22 < Compudj> dgoulet, cbab: and the lttng-modules tracer did not complain <br /> about any timeout, nor did the start operation<br />08:22 < Compudj> dgoulet, cbab: fyi, the ping flood was running before I <br /> started tracing</p> LTTng-UST - Bug #311 (Resolved): Compatibility issue between liblttng-ust stable-2.0 and masterhttps://bugs.lttng.org/issues/3112012-07-19T16:02:29ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>11:42 < Compudj> that's a weird scenario<br />11:43 < Compudj> you had you app linked with liblttng-ust 2.0.4, generating <br /> packet headers with the uin32_t field<br />11:43 < Compudj> but the lttng-consumerd you have is probably linked with <br /> liblttng-ust master<br />11:44 < Compudj> which has generated unsigned long (64-bit) fields when <br /> flushing the last packets of each buffer<br />11:47 < Compudj> so it falls into compatibility issues between liblttng-ust <br /> stable-2.0 and master, in the case the consumer is linked to a <br /> newer version</p>
<p>11:52 < Compudj> we don't want to break compatibility between UST and <br /> lttng-tools in the 2.x series, not without a deprecation phase <br /> anyway<br />11:52 < Compudj> so I have to find a fix<br />11:53 < Compudj> I'm wondering, in terms of library versioning, if I should <br /> bump the master branch UST lib version<br />11:54 < Compudj> then I could pass, for each stream, which UST version they <br /> belong to (to the consumer)<br />11:54 < Compudj> and let the consumer use compatibility mode for older streams</p> LTTng-UST - Bug #252 (Resolved): lttng-ust does not override daemon() glibc callhttps://bugs.lttng.org/issues/2522012-06-05T19:02:42ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>daemon() performs a fork underneath, and uses a direct call to the glibc fork, so I suspect that lttng-ust fork lib should override daemon().</p> LTTng-tools - Bug #101 (Resolved): comapt-freebsd branch: make -j10 failshttps://bugs.lttng.org/issues/1012012-02-23T22:51:10ZMathieu Desnoyersmathieu.desnoyers@efficios.com
make: don't know how to make ../../src/common/libcompat.la. Stop
<ul>
<li>Error code 1<br />1 error</li>
<li>Error code 1<br />1 error</li>
<li>Error code 1<br />1 error</li>
</ul>
<p>We should not have 2 interdependent libs in the same directory, as automake cannot handle it. We need to move one of these libraries into a subdirectory and force the build order.</p> LTTng-tools - Bug #100 (Resolved): After sessiond major failure (e.g. segfault), new sessiond han...https://bugs.lttng.org/issues/1002012-02-23T22:25:36ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>how to reproduce:</p>
<p>killall -9 lttng-sessiond</p>
<p>restart sesssiond</p>
<p>send commands to sessiond that require it to spawn the consumer.</p>
<p>It will hang for 30 seconds waiting on the previous consumer:</p>
<p>compudj@thinkos:~$ ps aux |grep lttng<br />root 29577 0.0 0.0 230296 1256 pts/0 tl+ 17:15 0:00 lttng-sessiond -vvv<br />compudj 29589 0.0 0.0 31444 1104 pts/6 S+ 17:15 0:00 lttng enable-channel test -u --num-subbuf 3<br />root 29591 0.0 0.0 72192 744 pts/0 Sl+ 17:15 0:00 lttng-consumerd --quiet -u --consumerd-cmd-sock /var/run/lttng/ustconsumerd64/command --consumerd-err-sock /var/run/lttng/ustconsumerd64/error<br />compudj 30511 0.0 0.0 112548 868 pts/9 S+ 17:26 0:00 grep lttng<br />root 32255 0.0 0.0 68052 712 ? Sl 14:50 0:00 lttng-consumerd --quiet -u --consumerd-cmd-sock /var/run/lttng/ustconsumerd64/command --consumerd-err-sock /var/run/lttng/ustconsumerd64/error</p>
<p>as we see, in that state, we have 2 consumers running.</p> LTTng-tools - Bug #89 (Resolved): sessiond does not handle channel creation errors for USThttps://bugs.lttng.org/issues/892012-02-22T00:49:27ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>With UST commit:</p>
<p>commit e52b0723a0f08966ee0913707b549235b2bce96d<br />Author: Mathieu Desnoyers <<a class="email" href="mailto:mathieu.desnoyers@efficios.com">mathieu.desnoyers@efficios.com</a>><br />Date: Tue Feb 21 19:20:51 2012 -0500</p>
<pre><code>Fix: Return -EINVAL instead of print warning if non power of 2 size/num_subbuf</code></pre>
<pre><code>Reported-by: Tan Dung Le Tran &lt;<a class="email" href="mailto:tan.dung.le.tran@ericsson.com">tan.dung.le.tran@ericsson.com</a>&gt;<br /> Signed-off-by: Mathieu Desnoyers &lt;<a class="email" href="mailto:mathieu.desnoyers@efficios.com">mathieu.desnoyers@efficios.com</a>&gt;</code></pre>
<p>lttng create<br />lttng enable-channel test -u --num-subbuf 3 # known bad number of buffers.<br />lttng enable-event -u -a<br />lttng start</p>
<p>./hello</p>
<p>segfaults lttng-sessiond. Backtrace:</p>
<p>#0 ustctl_create_stream (sock=19, channel_data=0x0, _stream_data=0xf040a8)<br /> at ustctl.c:274<br /> lum = {handle = 0, cmd = 96, u = {channel = {overwrite = 0, subbuf_size = 0, <br /> num_subbuf = 0, switch_timer_interval = 0, read_timer_interval = 0, <br /> output = LTTNG_UST_MMAP, padding = '\000' <repeats 287 times>}, stream = {<br /> padding = '\000' <repeats 15 times>, u = {<br /> padding = '\000' <repeats 287 times>}}, event = {<br /> instrumentation = LTTNG_UST_TRACEPOINT, name = '\000' <repeats 255 times>, <br /> loglevel_type = LTTNG_UST_LOGLEVEL_ALL, loglevel = 0, <br /> padding = '\000' <repeats 15 times>, u = {<br /> padding = '\000' <repeats 287 times>}}, context = {<br /> ctx = LTTNG_UST_CONTEXT_VTID, padding = '\000' <repeats 15 times>, u = {<br /> padding = '\000' <repeats 287 times>}}, version = {major = 0, minor = 0, <br /> patchlevel = 0}, tracepoint = {name = '\000' <repeats 255 times>, <br /> loglevel = 0, padding = '\000' <repeats 15 times>}}}<br /> lur = {handle = 1407809808, cmd = 32560, ret_code = 4328272, ret_val = 0, u = {<br /> channel = {memory_map_size = 4370524}, stream = {memory_map_size = 4370524}, <br /> version = {major = 4370524, minor = 0, patchlevel = 1498267712}, <br /> tracepoint = {<br /> name = "\\\260B\000\000\000\000\000@\300MY0\177\000\000\003\000\000\000\000\000\000\000\357\265@\000\350\003\000\000\350\003\000\000\370\001\000\000H\346\357\000\000\000\000\000H\346\357\000\000\000\000\000\370\001\000\000\000\000\000\000 z\351S0\177\000\000+\316@\000\000\000\000\000\240\021GXi6LT \177\357\000\000\000\000\000\330\345\356\000\000\000\000\000\000\346\357\000\000\000\000\000\020`iI0\177\000\000\004\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000m\231 \242*2l\226\060`iI0\177\000\000(\346\357\000\000\000\000\000\060\020\000\000\000\000\000\000\270\276EX0\177\000\000?EX0\177\000\000\000z\351S0\177\000\000 \020\000\000\000\000\000\000P\201\357\000c\000\000\000P\020\000\000\000\000\000\000\300y\351S\003\001\000\000?\310A", '\000' <repeats 13 times>..., loglevel = 4128, <br /> padding = "\000\000\000\000`\276EX0\177\000\000`\276EX"}}}<br /> stream_data = 0xf040d0<br /> ret = <optimized out><br /> fd = <optimized out><br /> err = 0<br /> <i>func</i> = "ustctl_create_stream" <br />#1 0x000000000040ecfa in ust_app_start_trace (usess=0xeee5d0, app=0xef7f20)<br /> at ust-app.c:1958<br /> ret = 0<br /> iter = {iter = {node = 0xf00688, next = 0xf00e78}}<br /> ua_sess = 0xefe600<br /> ua_chan = 0xf00400<br /> ustream = 0xf030a0<br /> consumerd_fd = 0<br /> <i>func</i> = "ust_app_start_trace" <br />#2 0x000000000040fac2 in ust_app_global_update (usess=0xeee5d0, sock=19)<br /> at ust-app.c:2296<br /> ret = 0<br />....</p>
<p>So it looks like a NULL channel object is still around and is being used to create a stream.</p> Babeltrace - Bug #82 (Resolved): Need to generically print tracer version info in verbose modehttps://bugs.lttng.org/issues/822012-02-20T20:26:21ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-modules - Bug #81 (Resolved): Need to standardize versioning across toolchainhttps://bugs.lttng.org/issues/812012-02-20T19:54:51ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-UST - Bug #80 (Resolved): Need to standardize versioning across toolchainhttps://bugs.lttng.org/issues/802012-02-20T19:54:25ZMathieu Desnoyersmathieu.desnoyers@efficios.comLTTng-tools - Bug #79 (Resolved): Need to standardize versioning across toolchainhttps://bugs.lttng.org/issues/792012-02-20T19:53:37ZMathieu Desnoyersmathieu.desnoyers@efficios.comBabeltrace - Bug #64 (Resolved): Properly separate libctf and libbabeltracehttps://bugs.lttng.org/issues/642012-02-17T20:10:40ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>Right now, the "libbabeltrace" and "libctf" parts are one big inter-dependant blob.</p>
<p>Ideally we should separate both of those in distinct libraries, each with their own public API. (.h's and whatnot)<br />libbabeltrace will probably depend on libctf, since it uses it as IR, but the dependency would be one-way.</p>
<p>This would allow applications to implement CTF parsing without having to import the babeltrace-specific libraries.</p>
<p>Moreover, it will allow LTTngTop to use libbabeltrace, which it cannot do it its current state because of missing open with mmap support.</p> LTTng-UST - Bug #58 (Won't fix): sched_getcpu triggers a system call on glibc older than 2.14https://bugs.lttng.org/issues/582012-02-16T21:35:49ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>tracing "hello" with kernel tracing enabled lets us discover that sched_getcpu, supposed to be a vDSO, actually triggers a system call:</p>
<p>[16:05:32.991027867] (+0.000000909) ust_tests_hello:tptest: { 1 }, { intfield = 9, intfield2 = 0x9, longfield = 9, netintfield = 9, netintfieldhex = 0x9, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2 }<br />[16:05:32.991029728] (+0.000001861) sys_getcpu: { 1 }, { cpup = 0x7FFF1B010350, nodep = 0x0, tcache = 0x7FC76A03E7D8 }<br />[16:05:32.991033220] (+0.000003492) exit_syscall: { 1 }, { ret = 0 }<br />[16:05:32.991034256] (+0.000001036) ust_tests_hello:tptest: { 1 }, { intfield = 10, intfield2 = 0xA, longfield = 10, netintfield = 10, netintfieldhex = 0xA, arrfield1 = [ [0] = 1, [1] = 2, [2] = 3 ], arrfield2 = "test", _seqfield1_length = 4, seqfield1 = [ [0] = 116, [1] = 101, [2] = 115, [3] = 116 ], _seqfield2_length = 4, seqfield2 = "test", stringfield = "test", floatfield = 2222, doublefield = 2 }<br />[16:05:32.991036204] (+0.000001948) sys_getcpu: { 1 }, { cpup = 0x7FFF1B010350, nodep = 0x0, tcache = 0x7FC76A03E7D8 }<br />[16:05:32.991036936] (+0.000000732) exit_syscall: { 1 }, { ret = 0 }</p>
<p>It will need to be investigated at the glibc and kernel level, and maybe we will have to implement our own wrapper over the vDSO.</p> LTTng-tools - Bug #49 (Invalid): lttng destroy: sendmsg: Bad file descriptorhttps://bugs.lttng.org/issues/492012-02-16T03:11:50ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>root@thinkos:/home/compudj/work/lttng-modules# lttng create<br />Session auto-20120215-221107 created.<br />Traces will be written in /root/lttng-traces/auto-20120215-221107<br />root@thinkos:/home/compudj/work/lttng-modules# lttng enable-event -k -a<br />All kernel events are enabled in channel channel0<br />root@thinkos:/home/compudj/work/lttng-modules# lttng start<br />Tracing started for session auto-20120215-221107<br />root@thinkos:/home/compudj/work/lttng-modules# lttng stop<br />Tracing stopped for session auto-20120215-221107<br />root@thinkos:/home/compudj/work/lttng-modules# lttng destroy<br />Session auto-20120215-221107 destroyed at /root</p>
<p>but the lttng-sessiond -vvv gives:<br />DEBUG1: Destroying session auto-20120215-221107 [in session_destroy() at session.c:155]<br />DEBUG1: Updating kernel poll set [in update_kernel_poll() at main.c:671]<br />DEBUG1: Thread kernel polling on 2 fds [in thread_manage_kernel() at main.c:828]<br />DEBUG1: Sending response (size: 16, retcode: Success) [in thread_manage_clients() at main.c:3672]<br />sendmsg: Bad file descriptor<br />Error: Failed to send data back to client<br />DEBUG1: Clean command context structure [in clean_command_ctx() at main.c:457]<br />DEBUG1: Accepting client command ... [in thread_manage_clients() at main.c:3573]</p>
<p>upon destroy</p>