This is the mail archive of the
mailing list for the GDB project.
Thread stuck in ioctl
- From: Jüri Põldre <jyri dot poldre at artecdesign dot com>
- To: <gdb at sourceware dot org>
- Date: Thu, 14 Oct 2010 15:05:37 +0300
- Subject: Thread stuck in ioctl
DVB hardware platform is using ioctl based interface to engage kernel calls
from userspace. The code base is rather large and extends inside kernel to
two separate processors - one for video and another for audio decoding.
During bad signal quality one of these calls locks up causing userspace
thread to do the same. After some time watchdog resets device.
Although it is possible to add debug printouts to this interface doing so
would cause a lot of traffic and also shift process timings. Embedded
platforms are relatively slow and lot of debug info chokes them pretty fast.
It would be very helpful to print backtrace of stuck thread.
It is possible to start gdb debugging in non-stop mode. After ioctl locks
switch to locked thread with "thread nr" command works but nothing can be
done as it is running. Stopping thread with "interrupt" command does not
succeed because breakpoint in thread is never reached causing gdb to wait
Scheduler should be aware of locked thread environment. Can you tell me if
this is fundamental issue or can it be overcome? It is ok that program
cannot be debugged further, only information about stuck thread backtrace
HW platform MIPS32r2 300 MHz, Linux 2.6.18, gdb 7.2