This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 forever.
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 is required.

HW platform MIPS32r2 300 MHz, Linux 2.6.18, gdb 7.2

Jüri Põldre.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]