Hi, I am having a mutex deadlock in my code that I can relatively reliable trigger when running the test case under valgrind with memcheck. Now of cource this is not an error for memcheck and thus it hangs. When I run valgrind with --db-aatch I can Ctrl-C and print the backtrace. the trouble is I know the place already where it hangs. I need to get the back trace from the other threads currently holding the mutex. (gdb) info threads * 1 process 22412 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
(gdb) bt Thread 1 (process 22412): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x0000000009b955d9 in _L_lock_953 () from /lib/libpthread.so.0 #2 0x0000000009b953fb in __pthread_mutex_lock (mutex=0xffd26d8) at pthread_mutex_lock.c:61 #3 0x00000000099166ac in IA__g_static_rec_mutex_lock (mutex=0xffd26d0) at /tmp/glib2.0.0xzuTt/glib2.0-2.24.1/glib/gthread.c:1420 where are the other threads? Stefan ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users