5

gdbクラッシュしたプロセスのコア ダンプを使用して事後分析モードで使用しようとしています。スタック トレースを取得できますが、問題の関数の実際の場所を表示する代わりにgdb、問題の関数が呼び出す 2 行のインライン関数の行番号が表示されます。

インライン関数は、非常に多くの場所で呼び出されます。クラッシュを引き起こした呼び出しを見つけるにはどうすればよいですか? インライン関数のすぐ周りのコードを見つけるにはどうすればよいですか?

4

3 に答える 3

4

問題のスタック フレームに移動し、命令ポイント (例: p $rip) を出力し、それを使用して、例: "addr2line -e -i 0x84564756" で手動で検索します。

これはスケーリングしませんが、少なくとも機能します。

于 2009-12-18T04:42:02.393 に答える
2

「インライン関数への多くの呼び出し」はすべて、単一の「問題のある関数」内から発生していると思います(そうでなければ、あなたの質問は私には意味がありません)。

でクラッシュ ポイントの IP アドレスを書き留めてから、出力でその IP アドレスをGDB使用"objdump -dS ./a.out"して検索することをお勧めします。

于 2009-02-23T05:16:48.727 に答える
-1

OPTIMIZE を NO に設定して (例: setenv OPTIMIZE NO)、プロジェクトを再構築することができます。これにより、コンパイラはコードを最適化しないため、関数呼び出しがインライン化されない可能性があります。

于 2009-02-18T19:09:09.170 に答える