Can GDB display a list of pthread mutexes held by each thread?

I have GDB attached to a deadlocked ap开发者_如何学Goplication 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?

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").

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.

GDB could be able to display this information, but they didn't implement this functionality: it requires a cooperation between the debugger and the thread library, though the libthread_db library.

DBX under Solaris -- at least -- (both from Sun, it helps!) implements correctly this feature (look for the Locks part)