Menu
I have GDB attached to a deadlocked application written with pthreads. There are ~10 threads that are all blocked, and I'd like to know which locks are held by which threads. This is possible in WinDbg using SOS.dll; is this possible in GDB?
737
Use the "info threads" command to see the IDs of currently known threads. The GDB thread debugging facility allows you to observe all threads while your program runs--but whenever GDB takes control, one thread in particular is always the focus of debugging. This thread is called the current thread.
A pthread mutex is a structure of type pthread_mutex_t that implement a behavior based on the Pthread mutexes. An MI mutex is a structure built into the machine that implement a similar sort of serialization construct. The maximum number of recursive locks by the owning thread is 32,767.
A mutex is initialized in the beginning of the main function. The same mutex is locked in the 'doSomeThing()' function while using the shared resource 'counter' At the end of the function 'doSomeThing()' the same mutex is unlocked. At the end of the main function when both the threads are done, the mutex is destroyed.
On at least one flavor of Linux, the C++11 std::mutex has a member called __owner which contains the thread id of the thread that currently has the mutex locked. Using "info threads" in gdb shows the thread numbers used by gdb along with the thread ids (see the "LWP" number), allowing you to switch to that thread ("thread N") and then examine the call stack ("backtrace").
192
It's not GDB you should be asking about, but rather the specific pthread library and OS you are using.
The pthread library implements mutexes in cooperation with the kernel via some set of system calls. If its implementation of mutexes embeds something to tie the last thread holding the mutex into the mutex data structure, then you can use GDB to get at that information.
It is possible your kernel tracks that information. Under Mac OS X, for example, the collection of GDB scripts bundled with the kernel debugging kit, kgmacros, includes a command showallmtx that will do exactly what you want. The catch: to use it, you have to be debugging the machine's kernel at the time, which means you need to be doing the debugging using a different machine.
Of course, you might have a /dev/kmem device file, which would let you poke around in the kernel's memory and access the necessary data structure, provided you can locate it.
But this all really depends on your system - your pthread library and OS kernel - not on GDB.
You could also try creating a mutex of type PTHREAD_MUTEX_ERRORCHECK; this will cause pthread_mutex_lock() to return EDEADLK instead of deadlocking. You can then break when that occurs and root around in your non-deadlocked process.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
