debuggingfutex锁

我有一个等待futex的进程：

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

我怎样才能最好地debugging这种情况？ 我可以识别谁拥有futex？ 有没有类似于ipcs和ipcrm的工具，但对于futexes？

为什么一个线程互斥体被认为比一个futex“慢”呢？

在futex之前，线程/进程如何在Linux中停留和唤醒？

在不相关的进程之间共享futex

FUTEX_WAIT和FUTEX_WAIT_PRIVATE有什么区别？

Linux futex系统调用虚假唤醒返回值为0？

尝试使用gdb -p *PID*然后运行where或bt来查看回溯。

对于那些已经删除了调试符号的二进制文件和库，它不会非常有用，但是你可能能够从上下文中推导出一个公平的位。 它可能能够指示复杂进程挂起的哪一部分，然后您可以检查源的正确部分来搜索锁。

我有一个c + +代码相同的问题。 运行Ubuntu 12.10 64bit。 它似乎在2007年，类似的问题，在libc是越野车（也许还是？）。

我开始一个在系统调用中运行traceroute的pthread。 printf在系统前后显示，操作系统挂起在系统调用中，不执行traceroute。

我不知道，如果我的Linux再次因为Ubuntu的更新而中断，或者它是一个libc相关的错误。 由于许多应用程序似乎有“相似”的问题，我认为它卡在用户空间的某个地方。

我的c + +代码运行在32位系统，甚至64位osx完美，所以我认为，Ubuntu 12.10 + 64位libc组合是打破。