linux - futex ロックをデバッグする

Question

私はfutexを待っているプロセスを持っています:

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

このような状況を最適にデバッグするにはどうすればよいですか? フューテックスの保有者を特定できますか? ipcs と ipcrm に似ているが、futex 用のツールはありますか?

score 3 · Accepted Answer

またはを使用gdb -p *PID*して実行し、バックトレースを確認してください。wherebt

デバッグシンボルが取り除かれたバイナリやライブラリではそれほど役に立ちませんが、コンテキストからかなりのことを推測できる場合があります。複雑なプロセスのどの部分がハングしているかを示すことができる場合があり、ソースの適切な部分を調べてロックを検索できます。

score 0 · Accepted Answer

私は、C++ コードで同じ問題を抱えています。ubuntu 12.10 64ビットを実行しています。libc にバグがあった 2007 年にも同様の問題が発生したようです (そして、まだバグがあるのでしょうか?)。

システムコールで traceroute を実行する pthread を開始します。システムの前後の Printf は、traceroute を実行せずに、オペレーティングシステムがシステムコールでハングしていることを示します。

ubuntu の更新が原因で Linux が再び壊れたのか、それとも libc 関連のバグなのかはわかりません。多くのアプリケーションが「同様の」問題を抱えているように見えるので、ユーザー空間のどこかでスタックしていると思います。

私の c++ コードは 32 ビットシステムや 64 ビット osx でも完全に動作するため、ubuntu 12.10 + 64 ビット libc の組み合わせが壊れていると思います。

2 に答える 2