5

まれにデッドロックが発生するマルチスレッド C++ プログラムがあります。この問題は再現が難しく、リモート マシンでしか再現できません。この問題を解決するために使用したい方法は

  1. プログラムを実行する
  2. デッドロックを待つ
  3. コアダンプを生成するために中止信号を送信します
  4. ダンプをローカル マシンにコピーする
  5. gdb を使用してデバッグします

リモート マシンに gdb がなく、何もインストールできません。問題は、コア ダンプ (リモート マシンでデッドロックされたプロセスまたは正常に実行されているプロセスから取得) をデバッグしているときに、ほとんどのスレッドのバック トレースが次のようにしか表示されないことです。

(gdb) ところで
#0 pthread_cond_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:261
#1 0x0000000000000000 in ?? ()

「-g -O1」オプションでコンパイルされた静的にリンクされたバイナリを使用しています。ローカル マシンで同じバイナリのプロセスを中止すると、gdb はコア ダンプからスタック全体を抽出でき、そのような問題はありません (ただし、デッドロックは再現できません)。リモート マシンは SLES で、ローカル マシンは ubuntu です。

何か案が？

編集：

同じ問題を抱えている他の誰かを見つけましたが、まだ解決策はありません: http://groups.google.com/group/google-coredumper/browse_thread/thread/2ca9bcf9465d1050 (私は Google コアダンパーを使用していませんが、Google コアダンパーが失敗したようです同じエラーで、これはおそらく問題が SLES 11 にあることを示唆しています)

4

2 に答える 2

3

gcore を使用して、中止せずにコア ファイルを作成することもできます。リモートホストで pstack を実行して (インストールされていると仮定して)、その方法でバックトレースを取得できるかどうかを確認しましたか?

そうしないと、アプリケーションで使用される共有オブジェクトがローカル ホストとリモート ホストで異なる場合、gdb はメモリ オフセットを適切に一致させることができず、バックトレースが混乱する可能性があります。関連するすべてのファイルをリモートホストからローカルの場所にコピーできる場合.soは、通常インストールされているバージョンの代わりに gdb にそれらから読み取るように指示できると思います。

編集: ビルド マシンで pstack を実行してみて、スタックを取得できるかどうかを確認してください。

于 2011-07-28T17:19:43.973 に答える
1

あなたのglibcの年齢は何歳ですか？あなたはおそらくこれを見逃していますか？

commit ad2be8527ac0f19f129fc4519d823cbe48239c78
Author: Ulrich Drepper <drepper@redhat.com>
Date:   Sun Apr 13 08:36:19 2003 +0000

    Update.

        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: Add unwind info.
        * sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S: Likewise.
        * sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S: Likewise.
于 2011-07-29T15:58:34.293 に答える