Question

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?

Answer 1

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.