Is it possible to define a stream containing a mutex?

Question

First, I use the pthread library to write a multi-threaded C program. Threads always depend on pending mutexes. When I use the strace utility to find a thread in the FUTEX_WAIT state, I want to know which thread is holding this mutex at the time. But I do not know how I could do this. Are there any utilities?

Someone told me that the Java virtual machine supports this, so I want to know if Linux supports this feature.

Answer 1

For this, you can use knowledge of the internal elements of the mutex. This is usually not a good idea, but it is good for debugging.

On Linux with the NPTL implementation of pthreads (which is any modern glibc), you can examine the __data.__owner member of the pthread_mutex_t structure to find out which thread is currently blocked. Here's how to do it after joining a process using gdb :

 (gdb) thread 2 [Switching to thread 2 (Thread 0xb6d94b90 (LWP 22026))]#0 0xb771f424 in __kernel_vsyscall () (gdb) bt #0 0xb771f424 in __kernel_vsyscall () #1 0xb76fec99 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0 #2 0xb76fa0c4 in _L_lock_89 () from /lib/i686/cmov/libpthread.so.0 #3 0xb76f99f2 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0 #4 0x080484a6 in thread (x=0x0) at mutex_owner.c:8 #5 0xb76f84c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #6 0xb767784e in clone () from /lib/i686/cmov/libc.so.6 (gdb) up 4 #4 0x080484a6 in thread (x=0x0) at mutex_owner.c:8 8 pthread_mutex_lock(&mutex); (gdb) print mutex.__data.__owner $1 = 22025 (gdb) 

(I switch to a hovering thread, do backtracking to find the pthread_mutex_lock() it is stuck on; change the stack frames to find out the name of the mutex that it is trying to block, then print the owner of that mutex). This suggests that the culprit is the thread with LWP ID 22025.

Then you can use thread find 22025 to find out the gdb thread number for that thread and switch to it.

Answer 2

I don’t know any such object, so I don’t think that you can handle it so easily - and probably it will not be as informative as you think, helping to debug your program. As low-tech as it might seem, enrollment is your friend in debugging these things. Start building your own little sign-up features. They don’t have to be fantasy, they just need to do the work during debugging.

Sorry for C ++, but something like:

 void logit(const bool aquired, const char* lockname, const int linenum) { pthread_mutex_lock(&log_mutex); if (! aquired) logfile << pthread_self() << " tries lock " << lockname << " at " << linenum << endl; else logfile << pthread_self() << " has lock " << lockname << " at " << linenum << endl; pthread_mutex_unlock(&log_mutex); } void someTask() { logit(false, "some_mutex", __LINE__); pthread_mutex_lock(&some_mutex); logit(true, "some_mutex", __LINE__); // do stuff ... pthread_mutex_unlock(&some_mutex); } 

Journaling is not an ideal solution, but there is nothing. Typically, you get what you need to know.

Answer 3

Typically, libc / platform calls are abstracted by the OS abstraction layer. Dead mutex locks can be tracked using the owner variable and pthread_mutex_timedlock. Whenever a thread blocks, it must update the variable with its own tid (gettid () and may also have another variable to hold the pthread identifier). Therefore, when other threads are blocked and go to pthread_mutex_timedlock, it can print the owner value of tid and pthread_id. this way you can easily recognize the owner stream. please find the code snippet below, note that all error conditions are not processed

 pid_t ownerTid; pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; class TimedMutex { public: TimedMutex() { struct timespec abs_time; while(1) { clock_gettime(CLOCK_MONOTONIC, &abs_time); abs_time.tv_sec += 10; if(pthread_mutex_timedlock(&mutex,&abs_time) == ETIMEDOUT) { log("Lock held by thread=%d for more than 10 secs",ownerTid); continue; } ownerTid = gettid(); } } ~TimedMutex() { pthread_mutex_unlock(&mutex); } }; 

There are other ways to detect dead locks, perhaps this link may help http://yusufonlinux.blogspot.in/2010/11/debugging-core-using-gdb.html .

Answer 4

Please read the link below. This has a general solution for finding the owner of a castle. It works even if it is locked in a library and you do not have the source code.

https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Deadlocks