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

Reply via email to