Bug #735
closed
lttng-sessiond crashes on mx6q
Added by Stefan Seefeld almost 11 years ago.
Updated almost 11 years ago.
Description
The following sequence of commands fails on a sabrelite board with yocto and a recent LTTng 2.4 rc snapshot:
lttng create
lttng enable-event -a -u
lttng start
...would yield:
Error: Session name not found
It turns out that the "lttng enable-event -a -u" command results in the session daemon to crash.
uname reports "Linux mx6q 3.8.13.13 #1 SMP PREEMPT Mon Feb 17 20:09:54 PKT 2014 armv7l GNU/Linux"
Files
- Project changed from LTTng-UST to LTTng-tools
- Target version deleted (
2.4)
I need some gdb backtrace or/and sessiond log to go forward with that.
The last lines of lttng-sessiond -vvv are:
DEBUG1 [4449/4501]: Spawning consumerd (in spawn_consumerd() at ../../../../lttng-tools/src/bin/lttng-sessiond/main.c:2153)
DEBUG2 [4449/4501]: Consumer pid 4510 (in start_consumerd() at ../../../../lttng-tools/src/bin/lttng-sessiond/main.c:2339)
DEBUG2 [4449/4501]: Spawning consumer control thread (in start_consumerd() at ../../../../lttng-tools/src/bin/lttng-sessiond/main.c:2342)
DEBUG1 [4449/4511]: [thread] Manage consumer started (in thread_manage_consumer() at ../../../../lttng-tools/src/bin/lttng-sessiond/main.c:992)
DEBUG1 [4510/4510]: Using 32-bit UST consumer at: /usr/local/lttng-sabrelite-mel/lib/lttng/libexec/lttng-consumerd (in spawn_consumerd() at ../../../../lttng-tools/src/bin/lttng-sessiond/main.c:2275)
DEBUG2 [4449/4511]: Receiving code from consumer err_sock (in thread_manage_consumer() at ../../../../lttng-tools/src/bin/lttng-sessiond/main.c:1077)
Warning: No tracing group detected
Apparently the crash happens at main.c:1244, because "consumer_data->metadata_sock.fd_ptr" is NULL so the dereference causes the crash.
I'm investigating further, FWIW.
In fact, just visually inspecting the "thread_manage_consumer" function, I notice that consumer_data->metadata_sock.fd_ptr is initialized at line 1100 only. There are, however, "goto" statements to "error" et al. before that point, so it seems entirely possible to end up in line 1244 with the fd_ptr not being initialized.
I'll try to confirm that this is in fact what crashes the app tomorrow.
The attached patch seems to fix the crash I'm observing.
(It corrects the handling of an error condition. I now need to investigate that error condition, but that's likely worth a separate bug report.)
- Status changed from New to Confirmed
- Target version set to 2.3
- Status changed from Confirmed to Resolved
Ok typo in my commit :( (Fxies...)
commit 965444556d7b554bee46df96d7893d3d7518fa86
Author: Stefan Seefeld <stefan@codesourcery.com>
Date: Tue Feb 25 22:44:30 2014 -0500
Fix: possible NULL deref. in sessiond error path
Fxies #735
Signed-off-by: Stefan Seefeld <stefan@codesourcery.com>
Signed-off-by: David Goulet <dgoulet@efficios.com>
Also available in: Atom
PDF