Futex lock debugging

Question

I have a process waiting for futex:

# strace -p 5538 Process 5538 attached - interrupt to quit futex(0x7f86c9ed6a0c, FUTEX_WAIT, 20, NULL 

What is the best way to debug this situation? Can I determine who holds futex? Are there any tools like ipcs and ipcrm, but for futexes?

Answer 1

Try using gdb -p *PID* and then run where or bt to see the backtrace.

This will not be spectacularly useful for binary files and libraries for which their debugging symbols have been dropped, but you can get a fair bit out of context. He can tell you what part of the complex process is hanging, and then you can check the correct part of the sources to find the lock.

Answer 2

I have the same problem with a piece of C ++ code. Running ubuntu 12.10 64 bit. This looks like a similar problem in 2007 when libc was buggy (and maybe still there?).

I run pthread, which runs traceroute in a system call. Printf before and after the system indicates that the operating system freezes during a system call WITHOUT tracing.

I'm not sure if my Linux is broken again due to an ubuntu update or if it is a libc-related error. Since many applications seem to have “similar” problems, I assume they are stuck somewhere in user space.

My C ++ code works fine on 32-bit systems and even on a 64-bit OS, so I assume that the combination of ubuntu 12.10 + 64bit libc is broken.