LTTng bugs repository: Issues
https://bugs.lttng.org/
https://bugs.lttng.org/themes/lttng/favicon/a.ico?1424972291
2023-12-21T17:25:29Z
LTTng bugs repository
Redmine
LTTng-modules - Bug #1408 (Resolved): Kernel crash when loading lttng-tracing module with IBT ena...
https://bugs.lttng.org/issues/1408
2023-12-21T17:25:29Z
Mohamed Khalfella
<pre>
[ 34.579608,053][ T2901] kernel BUG at arch/x86/kernel/cet.c:102!
[ 34.587325,053][ T2901] invalid opcode: 0000 [#1] PREEMPT SMP
[ 34.595431,03][ T2901] CPU: 53 PID: 2901 Comm: lttng-sessiond Tainted: G O 6.6.1+ #202312192336+7a8667e5f00a.kerneltesting.gcc-11
[ 34.620728,053][ T2901] RIP: 0010:exc_control_protection+0xce/0xd0
[ 34.620729,053][ T2901] Code: e9 87 04 00 00 4c 89 e6 48 89 ef e8 dc 1a 4e ff 44 89 ee 48 89 ef 5d 41 5c 41 5d e9 6c 04 00 00 48 c7 45 50 00 00 00 00 eb e6 <0f> 0b 66 0f 1f 00 41 56 49 89 f6 41 55 41 54 55 48 89 fd 0f 20 d0
[ 34.620731,053][ T2901] RSP: 0018:ffffc9002021bc68 EFLAGS: 00010002
[ 3 4 . 603][ T2901] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fff7ffff
g [ 0 ;314; .3603][ T2901] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 00000000fff7ffff
34.620734,053][ T2901] RBP: ffffc9002021bc88 R08: ffffffff862644a8 R09: 00000000fff7ffff
[ 34.620734,053][ T2901] R10: ffffffff826644c0 R11: ffffffff826644c0 R12: 0000000000000003
[ 34.620735,053][ T2901] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 34.620736,053][ T2901] FS: 00007f4fb64cf580(0000) GS:ffff88ff7fb40000(0000) knlGS:0000000000000000
[ 34.620737,053][ T2901] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 34.620737,053][ T2901] CR2: 0000559ff41c7668 CR3: 0000004bda6d4003 CR4: 0000000000f70ee0
[ 34.620738,053][ T2901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 34.620739,053][ T2901] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 34.620739,053][ T2901] PKRU: 55555554
[ 34.620740,053][ T2901] MSR 198h IA32 perf status 0x000018d300001c00
[ 34.620741,053][ T2901] MSR 19Ch IA32 thermal status 0x0000000088300800
[ 34.620743,053][ T2901] MSR 1B1h IA32 package thermal status 0x00000000882c0800
[ 34.620743,053][ T2901] Call Trace:
[ 34.620744,053][ T2901] <TASK>
[ 34.620748,053][ T2901] ? die+0x37/0x90
[ 34.620751,053][ T2901] ? do_trap+0xe0/0x110
[ 34.620752,053][ T2901] ? exc_control_protection+0xce/0xd0
[ 34.620754,053][ T2901] ? do_error_trap+0x70/0xb0
[ 34.620755,053][ T2901] ? exc_control_protection+0xce/0xd0
[ 34.620757,053][ T2901] ? exc_control_protection+0xce/0xd0
[ 34.620759,053][ T2901] ? exc_invalid_op+0x52/0x70
[ 34.868413,053][ T2901] ? exc_control_protection+0xce/0xd0
[ 34.868416,053][ T2901] ? asm_exc_invalid_op+0x1a/0x20
[ 34.894089,053][ T2901] ? exc_control_protection+0x5a/0xd0
[ 34.902365,053][ T2901] asm_exc_control_protection+0x26/0x30
[ 34.902367,053][ T2901] RIP: 0010:kallsyms_lookup_name+0x4/0xc0
[ 34.902369,053][ T2901] Code: 63 ff 48 63 04 bd c8 f1 29 82 85 c0 79 0a 48 f7 d0 48 03 05 a6 d8 1b 01 c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 66 0f 1f 00 <0f> 1f 44 00 00 55 48 83 ec 10 65 48 8b 04 25 28 00 00 00 48 89 44
[ 34.948612,053][ T2901] RSP: 0018:ffffc9002021bd30 EFLAGS: 00010296
[ 34.957567,053][ T2901] RAX: ffffffff8114bbe4 RBX: 0000000000000000 RCX: 0000000000000002
[ 34.957568,053][ T2901] RDX: ffffc9002021bc80 RSI: 0000000000000000 RDI: ffffffffa1031194
[ 34.957569,053][ T2901] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88c0877e5860
[ 34.957571,053][ T2901] R13: 00007f4fb9090441 R14: ffff88c9da9b1bf8 R15: ffffffff87a282f8
[ 35.023742,053][ T2901] ? 0xffffffffa12a7000
[ 35.054582,053][ T2901] lttng_events_init+0x11/0x2a0 [lttng_tracer]
[ 35.063999,053][ T2901] ? 0xffffffffa12a7000
[ 35.064002,053][ T2901] do_one_initcall+0x45/0x210
35.078967,053][ T2901] ? kmalloc_trace+0x29/0x90
[ 35.087025,053][ T2901] do_init_module+0x64/0x240
[ 35.094732,053][ T2901] init_module_from_file+0x8b/0xd0
[ 35.094734,053][ T2901] idempotent_init_module+0x17d/0x230
[ 35.094737,053][ T2901] __x64_sys_finit_module+0x5e/0xb0
[ 35.120981,053][ T2901] do_syscall_64+0x39/0x80
[ 35.128611,053][ T2901] entry_SYSCALL_64_after_hwframe+0x46/0xb0
[ 35.128613,053][ T2901] RIP: 0033:0x7f4fb8ca6a3d
[ 35.174961,053][ T2901] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000002
[ 35.231506,053][ T2901] R10: 000000000000001c R11: 0000000000000246 R12: 00007f4fb9090441
[ 35.231507,053][ T2901] R13: 000055d7e121fc20 R14: 0000000000000000 R15: 000055d7e1237560
[ 35.378236,053][ T2901] Dumping ftrace buffer:
[ 35.394649,053][ T2901] ---[ end trace 0000000000000000 ]---
35.911915,053][ T2901] RIP: 0010:exc_control_protection+0xce/0xd0
[ 35.953043,053][ T2901] RSP: 0018:ffffc9002021bc68 EFLAGS: 00010002
[ 35.953044,053][ T2901] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fff7ffff
[ 35.953047,053][ T2901] RBP: ffffc9002021bc88 R08: ffffffff862644a8 R09: 00000000fff7ffff
[ 36.008442,053][ T2901] R10: ffffffff826644c0 R11: ffffffff826644c0 R12: 0000000000000003
[ 36.008443,053][ T2901] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 36.008446,053][ T2901] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 36.065471,053][ T2901] CR2: 0000559ff41c7668 CR3: 0000004bda6d4003 CR4: 0000000000f70ee0
[ 36.065473,053][ T2901] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 36.065473,053][ T2901] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[ 36.065474,053][ T2901] PKRU: 55555554
[ 36.065475,053][ T2901] MSR 198h IA32 perf status 0x000018d300001c00
[ 36.065477,053][ T2901] MSR 19Ch IA32 thermal status 0x0000000088300800
[ 36.137537,053][ T2901] MSR 1B1h IA32 package thermal status 0x00000000882e0800
[ 36.137539,053][ T2901] Kernel panic - not syncing: Fatal exception
[ 36.145815,053][ T2901] was inactive. started with timeout 30s.
[ 36.145822,053][ T2901] Dumping ftrace buffer:
[ 36.145832,053][ T2901] (ftrace buffer empty)
[ 36.145856,053][ T2901] Kernel Offset: disabled
</pre><br />We saw this kernel crash when the kernel load lttng-trace module as part of module initialization on 6.6.1 Linux Kernel with compiled with CONFIG_X86_CET=y CONFIG_X86_KERNEL_IBT=y. The machine is running a cpu that supports IBT and the feature is enabled.
<pre>
lttng_events_init() ->
wrapper_get_pfnblock_flags_mask_init() ->
kallsyms_lookup_funcptr() ->
wrapper_kallsyms_lookup_name() ->
kallsyms_lookup_name_sym()
</pre><br />This is the codepath of the crash. I suspect that because the kallsyms_lookup_name address was obtained by means of kprobe the function call was an indirect function call to an instruction that is not endbr64 and this resulted in the kernel crash.<br /><pre>
(gdb) x/5i 0xffffffff8114bbe0
0xffffffff8114bbe0 <kallsyms_lookup_name>: nopw (%rax)
0xffffffff8114bbe4 <kallsyms_lookup_name+4>: nopl 0x0(%rax,%rax,1)
0xffffffff8114bbe9 <kallsyms_lookup_name+9>: push %rbp
0xffffffff8114bbea <kallsyms_lookup_name+10>: sub $0x10,%rsp
0xffffffff8114bbee <kallsyms_lookup_name+14>: mov %gs:0x28,%rax
(gdb) x/20bx 0xffffffff8114bbe0
0xffffffff8114bbe0 <kallsyms_lookup_name>: 0x66 0x0f 0x1f 0x00 0x0f 0x1f 0x44 0x00
0xffffffff8114bbe8 <kallsyms_lookup_name+8>: 0x00 0x55 0x48 0x83 0xec 0x10 0x65 0x48
0xffffffff8114bbf0 <kallsyms_lookup_name+16>: 0x8b 0x04 0x25 0x28
(gdb)
</pre>
<p>The instruction at 0xffffffff8114bbe4 is not endbr64 as one can see. Compiling the kernel with IBT disabled made the problem go away.</p>
LTTng-UST - Bug #1359 (Resolved): lttng can reap wrong child and get wrong status in get_wait_shm
https://bugs.lttng.org/issues/1359
2022-09-14T03:41:53Z
Tomas Weinfurt
<p>That code essentially use</p>
<p><code><br />pid = fork();<br />if (pid > 0) {<br /> wait();<br />}<br /></code><br /><a class="external" href="https://github.com/lttng/lttng-ust/blob/2d2d38713aea27077b690f2756a901c2a0c06f8c/src/lib/lttng-ust/lttng-ust-comm.c#L1584-L1597">https://github.com/lttng/lttng-ust/blob/2d2d38713aea27077b690f2756a901c2a0c06f8c/src/lib/lttng-ust/lttng-ust-comm.c#L1584-L1597</a></p>
<p>that is problematic because it translates to waitpid(-1, &wstatus, 0) on Linux and that can reap any unrelated process that existed during that time.<br />While the window is narrow it can be anything started before lttng was called or something started from unrelated thread.</p>
<p>The code rally should use <br />pid = waitpid(pid, &status, 0); <br />to avoid collecting unrelated status</p>
<p>Long saga and traces are captured here: <a class="external" href="https://github.com/dotnet/runtime/issues/74795">https://github.com/dotnet/runtime/issues/74795</a></p>
<p>lttng is loaded and initialized indirectly via msquic library and the code above interferes with tests runs.<br />It showed only on arm64 but that is probably just matter of timing.</p>
LTTng-UST - Bug #1355 (Resolved): Pointers are rejected by integer element compile time assertion...
https://bugs.lttng.org/issues/1355
2022-05-20T15:01:52Z
Christophe Bedard
<p>I've used the following tracepoint definition without any issues (build, runtime, or data analysis) with LTTng-UST 2.11:</p>
<pre><code class="c syntaxhl" data-language="c"><span class="n">TRACEPOINT_EVENT</span><span class="p">(</span>
<span class="n">TRACEPOINT_PROVIDER</span><span class="p">,</span>
<span class="n">message_link_periodic_async</span><span class="p">,</span>
<span class="n">TP_ARGS</span><span class="p">(</span>
<span class="k">const</span> <span class="kt">void</span> <span class="o">**</span><span class="p">,</span> <span class="n">subs_arg</span><span class="p">,</span>
<span class="k">const</span> <span class="kt">size_t</span><span class="p">,</span> <span class="n">num_subs_arg</span><span class="p">,</span>
<span class="k">const</span> <span class="kt">void</span> <span class="o">**</span><span class="p">,</span> <span class="n">pubs_arg</span><span class="p">,</span>
<span class="k">const</span> <span class="kt">size_t</span><span class="p">,</span> <span class="n">num_pubs_arg</span>
<span class="p">),</span>
<span class="n">TP_FIELDS</span><span class="p">(</span>
<span class="n">ctf_sequence_hex</span><span class="p">(</span><span class="k">const</span> <span class="kt">void</span> <span class="o">*</span><span class="p">,</span> <span class="n">subs</span><span class="p">,</span> <span class="n">subs_arg</span><span class="p">,</span> <span class="kt">size_t</span><span class="p">,</span> <span class="n">num_subs_arg</span><span class="p">)</span>
<span class="n">ctf_sequence_hex</span><span class="p">(</span><span class="k">const</span> <span class="kt">void</span> <span class="o">*</span><span class="p">,</span> <span class="n">pubs</span><span class="p">,</span> <span class="n">pubs_arg</span><span class="p">,</span> <span class="kt">size_t</span><span class="p">,</span> <span class="n">num_pubs_arg</span><span class="p">)</span>
<span class="p">)</span>
<span class="p">)</span>
</code></pre>
<p>This fails to build with LTTng-UST 2.13:</p>
<pre>
In file included from /usr/include/x86_64-linux-gnu/lttng/tracepoint-event.h:69,
from /builds/ros-tracing/ros2_tracing/build/tracetools/include/tracetools/tp_call.h:443,
from /builds/ros-tracing/ros2_tracing/tracetools/src/tp_call.c:18:
/builds/ros-tracing/ros2_tracing/build/tracetools/include/tracetools/tp_call.h:421:5: error: static assertion failed: "Non-integer type `subs` not supported as element of LTTNG_UST_FIELD_ARRAY or LTTNG_UST_FIELD_SEQUENCE"
421 | ctf_sequence_hex(const void *, subs, subs_arg, size_t, num_subs_arg)
| ^~~~~~~~~~~~~~~~
/builds/ros-tracing/ros2_tracing/build/tracetools/include/tracetools/tp_call.h:422:5: error: static assertion failed: "Non-integer type `pubs` not supported as element of LTTNG_UST_FIELD_ARRAY or LTTNG_UST_FIELD_SEQUENCE"
422 | ctf_sequence_hex(const void *, pubs, pubs_arg, size_t, num_pubs_arg)
| ^~~~~~~~~~~~~~~~
</pre>
<p>I have not tested on 2.12, but from looking at the original commit, this should only affect 2.13: <a class="external" href="https://github.com/lttng/lttng-ust/commit/2df82195d140b39c40abfb43d526804a9d14d3da">https://github.com/lttng/lttng-ust/commit/2df82195d140b39c40abfb43d526804a9d14d3da</a></p>
<p>This does not look like it is intended behaviour. I'm assuming I can work around this by explicitly using the pointers as integers, but of course a fix would be better (and a new/bugfix update for LTTng-UST 2.13 from the default packages on Ubuntu 22.04 would be ideal).</p>
LTTng-modules - Bug #975 (Confirmed): execve compat syscall exit syscall value issue
https://bugs.lttng.org/issues/975
2015-11-08T16:03:18Z
Mathieu Desnoyers
mathieu.desnoyers@efficios.com
<p>syscall_exit for execve changing the 32/64-bit compat mode for a process has wrong system call number on exit:</p>
<pre>
[19:36:57.188066018] (+0.000000616) sinkpad syscall_entry_execve: { cpu_id = 0 }, { filename = "/usr/bin/burnP6", argv = 0x7FFD275BBF40, envp = 0x7FFD275BBF50 }
[19:36:57.188162705] (+0.000000851) sinkpad module_get: { cpu_id = 0 }, { ip = 18446744071581118857, refcnt = 3, name = "binfmt_misc" }
[19:36:57.188170506] (+0.000000517) sinkpad module_put: { cpu_id = 0 }, { ip = 18446744071581118912, refcnt = 2, name = "binfmt_misc" }
[19:36:57.188630250] (+0.000000911) sinkpad random_get_random_bytes: { cpu_id = 0 }, { nbytes = 16, IP = 18446744071581461559 }
[19:36:57.188630781] (+0.000000531) sinkpad random_extract_entropy: { cpu_id = 0 }, { pool_name = "nonblocking", nbytes = 16, entropy_count = 0, IP = 18446744071583984742 }
[19:36:57.188634640] (+0.000001773) sinkpad sched_waking: { cpu_id = 0 }, { comm = "rngd", tid = 2177, prio = 120, target_cpu = 2 }
[19:36:57.188637855] (+0.000003215) sinkpad sched_stat_sleep: { cpu_id = 0 }, { comm = "rngd", tid = 2177, delay = 2656341 }
[19:36:57.188639681] (+0.000001826) sinkpad sched_wakeup: { cpu_id = 0 }, { comm = "rngd", tid = 2177, prio = 120, target_cpu = 2 }
[19:36:57.188641483] (+0.000000180) sinkpad power_cpu_idle: { cpu_id = 2 }, { state = 4294967295, cpu_id = 2 }
[19:36:57.188646080] (+0.000000644) sinkpad random_mix_pool_bytes_nolock: { cpu_id = 0 }, { pool_name = "nonblocking", bytes = 20, IP = 18446744071583981062 }
[19:36:57.188649456] (+0.000000788) sinkpad random_mix_pool_bytes_nolock: { cpu_id = 0 }, { pool_name = "nonblocking", bytes = 20, IP = 18446744071583981062 }
[19:36:57.188649704] (+0.000000248) sinkpad rcu_utilization: { cpu_id = 2 }, { s = "Start context switch" }
[19:36:57.188650149] (+0.000000182) sinkpad rcu_utilization: { cpu_id = 2 }, { s = "End context switch" }
[19:36:57.188652253] (+0.000001864) sinkpad sched_stat_wait: { cpu_id = 2 }, { comm = "rngd", tid = 2177, delay = 0 }
[19:36:57.188654080] (+0.000001827) sinkpad sched_switch: { cpu_id = 2 }, { prev_comm = "swapper/2", prev_tid = 0, prev_prio = 20, prev_state = 0, next_comm = "rngd", next_tid = 2177, next_prio = 20 }
[19:36:57.188658382] (+0.000000567) sinkpad sched_process_exec: { cpu_id = 0 }, { filename = "/usr/bin/burnP6", tid = 29058, old_tid = 29058 }
[19:36:57.188661040] (+0.000000020) sinkpad rcu_utilization: { cpu_id = 2 }, { s = "Start context switch" }
[19:36:57.188661415] (+0.000000375) sinkpad rcu_utilization: { cpu_id = 2 }, { s = "End context switch" }
[19:36:57.188662327] (+0.000000409) sinkpad sched_stat_runtime: { cpu_id = 2 }, { comm = "rngd", tid = 2177, runtime = 25827, vruntime = 1365908673 }
[19:36:57.188664216] (+0.000001266) sinkpad compat_syscall_exit_olduname: { cpu_id = 0 }, { ret = 0, name = 0 }
</pre>
LTTng-modules - Feature #962 (New): add x86 exceptions.h and irq_vectors.h instrumentation (and m...
https://bugs.lttng.org/issues/962
2015-10-22T19:47:19Z
Mathieu Desnoyers
mathieu.desnoyers@efficios.com
Userspace RCU - Feature #940 (New): Wire up sys membarrier on each architecture
https://bugs.lttng.org/issues/940
2015-09-26T16:00:41Z
Mathieu Desnoyers
mathieu.desnoyers@efficios.com
Userspace RCU - Bug #791 (Resolved): userspace-rcu tests need a few assertions
https://bugs.lttng.org/issues/791
2014-04-29T19:15:44Z
Daniel U. Thibault
daniel.thibault@drdc-rddc.gc.ca
<p>In six different spots, the <code>userspace-rcu</code> tests raise this warning:</p>
<p><code>attention : ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]</code></p>
<p>The simple fix is to wrap each offending <code>write()</code> in an <code>assert()</code> (turns out it's the same <code>write()</code> every time):</p>
<pre>
userspace-rcu/tests/benchmark/test_urcu_lfq.c, line 385:
assert(write (1, ".", 1));
userspace-rcu/tests/benchmark/test_urcu_lfs.c, line 469:
assert(write (1, ".", 1));
userspace-rcu/tests/benchmark/test_urcu_wfcq.c, line 495:
assert(write (1, ".", 1));
userspace-rcu/tests/benchmark/test_urcu_wfq.c, line 353:
assert(write (1, ".", 1));
userspace-rcu/tests/benchmark/test_urcu_wfs.c, line 483:
assert(write (1, ".", 1));
userspace-rcu/tests/benchmark/test_urcu_lfs_rcu.c, line 386:
assert(write (1, ".", 1));
</pre>
LTTng-modules - Bug #687 (Invalid): Crashing lttng-sessiond with enable-event --function
https://bugs.lttng.org/issues/687
2013-11-19T15:34:32Z
Daniel U. Thibault
daniel.thibault@drdc-rddc.gc.ca
<p>I managed to crash <code>lttng-sessiond</code> while fooling around with <code>kretprobe</code> events.</p>
<p>First I stopped the <code>lttng-sessiond</code> service and started a verbose root session manager to try and get the crash log (attached).</p>
<p>Then I did this:<br /><pre>
$ lttng create krpso
Session krpso created.
Traces will be written in /home/daniel/lttng-traces/krpso-20131119-095940
$ lttng enable-event -k krpso --function sys_open
kernel event krpso created in channel channel0
</pre></p>
<p>Having previously run the above tracing session and obtained this babeltrace:<br /><pre>
timestamp = 09:53:54.443925388, delta = +?.?????????, trace = /home/daniel/lttng-traces/krpso-20131119-095319/kernel, trace:hostname = sds-dut-vb, trace:domain = kernel, name = krpso_entry, stream.packet.context = { cpu_id = 0 }, event.fields = { ip = 0xFFFFFFFF81176A70, parent_ip = 0xFFFFFFFF81662142 }
timestamp = 09:53:54.443945296, delta = +0.000019908, trace = /home/daniel/lttng-traces/krpso-20131119-095319/kernel, trace:hostname = sds-dut-vb, trace:domain = kernel, name = krpso_return, stream.packet.context = { cpu_id = 0 }, event.fields = { ip = 0xFFFFFFFF81176A70, parent_ip = 0xFFFFFFFF81662142 }
</pre></p>
<p>I knew the absolute address of whatever called <code>sys_open</code>, so I continue with this:<br /><pre>
$ lttng enable-event -k krpso_parent --function 0xffffffff81662142
kernel event krpso_parent created in channel channel0
</pre></p>
<p>At which point the session manager just dies, with no message whatsoever.</p>
<p>If I instead do the equivalent symbol+offset command:<br /><pre>
$ lttng enable-event -k krpso_parent --function sys_open+0x4EB6D2
k event k created in channel c
Erreur du bus (core dumped)
</pre></p>
<p>Or this (just in case this is related to bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: utils_parse_size_suffix suffers from several problems (Resolved)" href="https://bugs.lttng.org/issues/633">#633</a>):<br /><pre>
$ lttng enable-event -k krpso_parent --function sys_open+5158610
k event k created in channel c
Erreur du bus (core dumped)
</pre></p>
LTTng-tools - Bug #357 (Resolved): Lttng event name length became one byte shorter when with filter.
https://bugs.lttng.org/issues/357
2012-10-01T18:23:24Z
huafeng Wang
hua.feng.wang@ericsson.com
<p>1.(provider:event) 127:127 without filter, it succeeded.</p>
<p>SC-1:~ # lttng enable-event this_domain_name_has_127_characters_it_does_not_follow_the_naming_convention_and_it_is_used_for_testing_purposes_only_yeah__127:this_event_name_has_127_characters_which_is_the_maximum_number_of_character_supported_man_i_still_need_some_more_characters_127 -u<br />UST event this_domain_name_has_127_characters_it_does_not_follow_the_naming_convention_and_it_is_used_for_testing_purposes_only_yeah__127:this_event_name_has_127_characters_which_is_the_maximum_number_of_character_supported_man_i_still_need_some_more_characters_127 created in channel channel0</p>
<p>2.(provider:event) 127:127 with filter, it failed.</p>
<p>SC-1:~ # lttng enable-event this_domain_name_has_127_characters_it_does_not_follow_the_naming_convention_and_it_is_used_for_testing_purposes_only_yeah__127:this_event_name_has_127_characters_which_is_the_maximum_number_of_character_supported_man_i_still_need_some_more_characters_127 -u --filter 'TenPs>3'<br />UST event this_domain_name_has_127_characters_it_does_not_follow_the_naming_convention_and_it_is_used_for_testing_purposes_only_yeah__127:this_event_name_has_127_characters_which_is_the_maximum_number_of_character_supported_man_i_still_need_some_more_characters_127 created in channel channel0<br />Error: Error setting filter<br />LTTng Trace Control 2.1.0-rc3 - Basse Messe</p>
<p>3.(provider:event) 127:126 with filter, it succeeded.</p>
<p>SC-1:~ # lttng enable-event this_domain_name_has_127_characters_it_does_not_follow_the_naming_convention_and_it_is_used_for_testing_purposes_only_yeah__127:this_event_name_has_127_characters_which_is_the_maximum_number_of_character_supported_man_i_still_need_some_more_characters_12 -u --filter 'TenPs>3'<br />UST event this_domain_name_has_127_characters_it_does_not_follow_the_naming_convention_and_it_is_used_for_testing_purposes_only_yeah__127:this_event_name_has_127_characters_which_is_the_maximum_number_of_character_supported_man_i_still_need_some_more_characters_12 created in channel channel0</p>
<p>Why we are short of char in eventName when we have filter. ?</p>
Babeltrace - Bug #322 (Invalid): library should not do exit() for error handling
https://bugs.lttng.org/issues/322
2012-08-07T20:44:41Z
Yannick Brosseau
yannick.brosseau@polymtl.ca
<p>It's impolite for a library to call exit().</p>
<p>We should find a better way to do error handling in those case</p>
<p>(<br />rom rpmlint:<br />libbabeltrace.x86_64: W: shared-lib-calls-exit /usr/lib64/libbabeltrace-ctf.so.0.0.0 exit@GLIBC_2.2.5<br />)<br />Its in the file:<br />babeltrace/formats/ctf/metadata/ctf-lexer.c</p>
LTTng-UST - Bug #267 (Won't fix): library should not do exit() for error handling
https://bugs.lttng.org/issues/267
2012-06-16T18:24:34Z
Yannick Brosseau
yannick.brosseau@polymtl.ca
<p>It's impolite for a library to call exit().</p>
<p>We should find a better way to do error handling in those case</p>
<p>(<br />See output of rpmlist ran on fedora:<br />lttng-ust.x86_64: W: shared-lib-calls-exit /usr/lib64/liblttng-ust-ctl.so.0.0.0 exit@GLIBC_2.2.5</p>
<p>)</p>
Babeltrace - Bug #223 (Won't fix): By some reason "cpu_id =" is re-introduced as default printout
https://bugs.lttng.org/issues/223
2012-04-25T14:10:04Z
Tan le tran
tan.dung.le.tran@ericsson.com
<p>Problem seen in both version of babeltrace 1.0.0-rc1 and rc2<br />ex:<br />[21:55:40.806412377] com_ericsson_......: { cpu_id = 1 }, { Sub_Name = "my string",..}</p>
<p>By default, babeltrace will printout "cpu_id =" string for the cpuId column.<br />Since this column is very obvious to detect, would it be possible to suppress the string "cpu_id =" ? If the user wants to see it, the option "-f all" can still be used.<br />In previous version, it used to print something like this:<br />ex:<br />[21:55:40.806412377] com_ericsson_......: { 1 }, { Sub_Name = "my string",..}</p>
Userspace RCU - Bug #152 (Resolved): library should not do exit() for error handling
https://bugs.lttng.org/issues/152
2012-03-05T22:07:14Z
Yannick Brosseau
yannick.brosseau@polymtl.ca
<p>It's impolite for a library to call exit().</p>
<p>We should find a better way to do error handling in those case</p>
<p>(<br />See output of rpmlist ran on fedora:<br />liburcu.x86_64: W: shared-lib-calls-exit /usr/lib64/liburcu-qsbr.so.1.0.0 exit@GLIBC_2.2.5<br />liburcu.x86_64: W: shared-lib-calls-exit /usr/lib64/liburcu.so.1.0.0 exit@GLIBC_2.2.5<br />liburcu.x86_64: W: shared-lib-calls-exit /usr/lib64/liburcu-mb.so.1.0.0 exit@GLIBC_2.2.5<br />liburcu.x86_64: W: shared-lib-calls-exit /usr/lib64/liburcu-bp.so.1.0.0 exit@GLIBC_2.2.5<br />liburcu.x86_64: W: shared-lib-calls-exit /usr/lib64/liburcu-signal.so.1.0.0 exit@GLIBC_2.2.5<br />)</p>
LTTng-modules - Feature #28 (Resolved): Implement the State Dump
https://bugs.lttng.org/issues/28
2012-02-11T23:57:19Z
Anonymous
<p>Re-implement LTTng 0.x 's statedump with the new toolchain.</p>
<p>This queries the state of each running process on the system at the start of a trace, and write it as a pseudo-event. This then allows the viewer to fill up its internal state system.</p>
<p>Tentatively aimed for 2.0, but it's not a blocker for the release.</p>
LTTng-UST - Bug #9 (Resolved): LTTng-UST java jni wrapper does not build with OpenJDK
https://bugs.lttng.org/issues/9
2012-02-10T01:20:47Z
Mathieu Desnoyers
mathieu.desnoyers@efficios.com
<p>Issue with<br />commit 94b6d0d14032fe9ac4e35b0521b3746a2e6e05d4</p>
<p>./configure --with-java-jdk=/usr/lib/jvm/java-6-openjdk-amd64<br />--with-jni-interface<br />make<br />[...]<br />javah -jni LTTNG_UST.class<br />error: cannot access LTTNG_UST.class<br />class file for LTTNG_UST.class not found<br />javadoc: error - Class LTTNG_UST.class not found.<br />Error: No classes were specified on the command line. Try -help.<br />make2: * [LTTNG_UST.h] Error 15<br />make2: Leaving directory `/home/compudj/git/lttng-ust/liblttng-ust-java'<br />make1: [all-recursive] Error 1<br />make1: Leaving directory `/home/compudj/git/lttng-ust'<br />make: ** [all] Error 2</p>