gdb
クラッシュしたプロセスのコア ダンプを使用して事後分析モードで使用しようとしています。スタック トレースを取得できますが、問題の関数の実際の場所を表示する代わりにgdb
、問題の関数が呼び出す 2 行のインライン関数の行番号が表示されます。
インライン関数は、非常に多くの場所で呼び出されます。クラッシュを引き起こした呼び出しを見つけるにはどうすればよいですか? インライン関数のすぐ周りのコードを見つけるにはどうすればよいですか?
問題のスタック フレームに移動し、命令ポイント (例: p $rip) を出力し、それを使用して、例: "addr2line -e -i 0x84564756" で手動で検索します。
これはスケーリングしませんが、少なくとも機能します。
「インライン関数への多くの呼び出し」はすべて、単一の「問題のある関数」内から発生していると思います(そうでなければ、あなたの質問は私には意味がありません)。
でクラッシュ ポイントの IP アドレスを書き留めてから、出力でその IP アドレスをGDB
使用"objdump -dS ./a.out"
して検索することをお勧めします。
OPTIMIZE を NO に設定して (例: setenv OPTIMIZE NO)、プロジェクトを再構築することができます。これにより、コンパイラはコードを最適化しないため、関数呼び出しがインライン化されない可能性があります。