問題タブ [postmortem-debugging]

基になるアプリケーションがしきい値を超えたときに、Windbg + Procdump を自動化して、ダンプごとに 60 秒間隔で 5 つのダンプを取得する方法があるかどうか疑問に思っています。

次のコマンドを使用して、Procdump を自動化しました。

しかし、アプリケーションが 800 か月のしきい値に達したときに、TTD (Windbg Time Travel Debugging) を 15 分間アクティブにする方法があるかどうかはわかりません。

私の目的は、PID、しきい値、各ダンプ間の時間、取得するダンプの数を取得する単一の .bat ファイルを作成し、TTD をアクティブにするかどうかをスクリプトに指示することです。

ここに悲しい話があります：

1. thedarkmod.x64デバッグ シンボルを別のファイルに移動して、自分のマシンで実行可能ファイルをビルドしましたthedarkmod.x64.debug。
2. この実行可能ファイルを gdb で実行しているときに、この実行可能ファイルでクラッシュが発生しました。彼女はgdb コマンドcore.1600を使用してコア ダンプを保存しました。generate-core-file
3. このコア ファイルをダウンロードし、起動して開きましたgdb ./thedarkmod.x64 core.1600。
4. スレッドを切り替えてbtコマンドを実行しましたが、適切なスタック トレースではなくゴミが表示されます。

注: ユーザーは私のthedarkmod.x64.debugファイルを持っておりbt、コア ダンプを保存する直前に実行すると、意味のあるスタック トレースが表示されます。

コア ダンプで gdb を起動すると、次のような多くの警告メッセージが表示されます。

• 下位のスレッド ライブラリに一致する libthread_db が見つかりません。スレッドのデバッグは利用できません。
• 警告: "libXXX.so" の .dynamic セクションが予期されたアドレスにありません (間違ったライブラリまたはバージョンの不一致?)

この質問によると、最初の警告はlibthread_db.so.1、コア ダンプが保存されたマシンと同じバージョンの を持っていない限り、マルチスレッド プログラムで有用なものが何も表示されないことを意味しているようです。ユーザーにこのファイルを見つけて提供するように依頼しましたが、役に立ちませんでした。libpthread.so.0次に、ファイルも提供するように依頼し、、、、と苦労しset solib-search-pathた後set sysroot、この警告を「libthread_dbを有効にしたスレッドデバッグ」に置き換えることができましたが、スタックトレースはまだ間違っていました。set auto-load safe-pathset libthread-db-search-path

質問は次のとおりです。

1. 環境が大きく異なる Linux マシンで生成されたコア ダンプを適切に検査する方法はありますか? 異なるカーネル、pthreads、glibc などを意味します。それを達成する方法に関する詳細な指示はどこにありますか?
2. のような gdb コマンドはありgenerate-core-file includecodeますか?

現時点では、提出されたすべてのコア ダンプに対して新しい Linux VM を作成する準備ができていないため、Linux コア ダンプはほとんど役に立たないことを認めなければなりません。

更新:適切なスタック トレースを取得することができました。

1. 「重複した質問」で提供された解決策はうまくいきませんでした。solib 関連の設定だけでは十分ではありませんでしset sysrootた。
2. 私の特定のケースでは、スタック トレースfreeは libc の関数内で終了しました。-fomit-frame-pointerおそらくほとんどのライブラリと同じようにコンパイルされているため、gdb はコール スタックをたどることができませんでした。libc.so.6ユーザーのマシンから取得したgdb ロードが役立つことを確認してください。

以下は、私が使用する gdb コマンドの完全なリストです (btもちろん、動作させるにはそれぞれのコマンドが必要です)。