LTTng bugs repository: Issueshttps://bugs.lttng.org/https://bugs.lttng.org/themes/lttng/favicon/a.ico?14249722912023-12-21T17:25:29ZLTTng bugs repository
Redmine LTTng-modules - Bug #1408 (Resolved): Kernel crash when loading lttng-tracing module with IBT ena...https://bugs.lttng.org/issues/14082023-12-21T17:25:29ZMohamed 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_shmhttps://bugs.lttng.org/issues/13592022-09-14T03:41:53ZTomas 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/13552022-05-20T15:01:52ZChristophe 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-UST - Bug #1306 (Resolved): Detect probe providers built against old lttng-ust (.so.0) in l...https://bugs.lttng.org/issues/13062021-04-13T20:00:35ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>We should ensure the new lttng-ust (.so.1) refuses old probe providers. Likewise for old tracepoint instrumentation.</p>
<p>We should also check whether it might be possible for an application and its shared libraries to end up linking against both .so.0 and .so.1 within the same process, for instance if only some of those are rebuilt. If this can happen, we should provide some mechanism to detect this.</p> LTTng - Bug #1284 (Resolved): UST consumer daemon should handle SIGBUShttps://bugs.lttng.org/issues/12842020-10-09T18:28:11ZMathieu Desnoyersmathieu.desnoyers@efficios.com
<p>There is an issue with the security model of lib ring buffer (lttng-ust) vs SIGBUS handling by consumer daemon. We do not trap SIGBUS in the consumer daemon. An application using ftruncate on a ring buffer shm could cause the consumer to be killed with SIGBUS.</p> LTTng-UST - Bug #1242 (Feedback): SEGV on process exit with shared libraryhttps://bugs.lttng.org/issues/12422020-03-05T00:35:47ZStephen Hemminger
<p>Our application has a main process and a dynamically loaded library.<br />Both are using Lttng userspace tracepoints.</p>
<p>On process exit (initiated by ctrl-C) the main process does its cleanup and calls dlclose() on the dynamic libary.<br />That part is handled normally.</p>
<p>The issue is that later the main process gets a SEGV in the lttng-ust library cleanup logic.<br />Does the lttng internals still have references to the unloaded memory.</p>
<p>[Switching to Thread 0xfffff722b010 (LWP 18895)]<br />0x0000fffff7ea3b1c in ?? () from /lib/liblttng-ust.so.0<br />(gdb) where<br />#0 0x0000fffff7ea3b1c in ?? () from /lib/liblttng-ust.so.0<br />#1 0x0000fffff7fdcb1c in <em>dl_fini () at dl-fini.c:138<br />#2 0x0000fffff79e12d0 in __run_exit_handlers (status=0, listp=0xfffff7b125c8 <</em>_exit_funcs>, <br /> run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108<br />#3 0x0000fffff79e1434 in __GI_exit (status=<optimized out>) at exit.c:139<br />#4 0x0000fffff79cdce8 in __libc_start_main (main=0xaaaaaaab2a60 <main>, argc=3, argv=0xfffffffffbf8, init=<optimized out>, <br /> fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:342<br />#5 0x0000aaaaaaab336c in _start () at ../sysdeps/aarch64/start.S:94<br />Backtrace stopped: previous frame identical to this frame (corrupt stack?)<br />(gdb) q<br />A debugging session is active.</p>
<pre><code>Inferior 1 [process 18895] will be killed.</code></pre> LTTng-modules - Bug #975 (Confirmed): execve compat syscall exit syscall value issuehttps://bugs.lttng.org/issues/9752015-11-08T16:03:18ZMathieu Desnoyersmathieu.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> Userspace RCU - Bug #791 (Resolved): userspace-rcu tests need a few assertionshttps://bugs.lttng.org/issues/7912014-04-29T19:15:44ZDaniel U. Thibaultdaniel.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 --functionhttps://bugs.lttng.org/issues/6872013-11-19T15:34:32ZDaniel U. Thibaultdaniel.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/3572012-10-01T18:23:24Zhuafeng Wanghua.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 handlinghttps://bugs.lttng.org/issues/3222012-08-07T20:44:41ZYannick Brosseauyannick.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 handlinghttps://bugs.lttng.org/issues/2672012-06-16T18:24:34ZYannick Brosseauyannick.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 printouthttps://bugs.lttng.org/issues/2232012-04-25T14:10:04ZTan le trantan.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 handlinghttps://bugs.lttng.org/issues/1522012-03-05T22:07:14ZYannick Brosseauyannick.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-UST - Bug #9 (Resolved): LTTng-UST java jni wrapper does not build with OpenJDKhttps://bugs.lttng.org/issues/92012-02-10T01:20:47ZMathieu Desnoyersmathieu.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>