4

コアに遭遇しましたが、そこからトレースバックを取得できません。2 つの質問があります。

  1. list コマンドの出力から、クラッシュの原因となった行またはクラッシュが発生した場所を特定できますか?
  2. それ以外の場合の対処方法。意味のあるデータを取得するには、heuristic-fence-post を何に設定する必要がありますか。0に設定しようとしましたが、うまくいきませんでした。

(gdb) ところで

0 0x00e67a24 in ?? ()

警告: GDB は 0xe67a24 で関数の開始を見つけることができません。

GDB is unable to find the start of the function at 0xe67a24

したがって、その関数のスタック フレームのサイズを特定できません。これは、GDB がそのスタック フレームまたはその下のフレームにアクセスできない可能性があることを意味します。この問題は、無効なプログラム カウンターまたはスタック ポインターが原因である可能性があります。しかし、GDB が単純に 0xe67a24 からさかのぼって関数の始まりのように見えるコードを検索する必要があると考える場合は、「set heuristic-fence-post」コマンドを使用して検索範囲を広げることができます。(gdb)

4

2 に答える 2

9

この問題が発生したときによく機能する回避策は、次のコマンドです。

x/100a $sp

これにより、シンボルを含むスタックがダンプされ、バックトレースの最近の部分がそこにある可能性があります。実際の現在のスタックフレームはまだ見つかりませんが、シンボルを持つ最新のものを見つける必要があります。

ターゲット アーキテクチャによっては、$sp を別のものにする必要がある場合があります。どのレジスタがスタック ポインタであっても。

gdb がコール スタックを見つけられない最も一般的なケースは、予想される ARM ABI 呼び出し規約を使用しない OpenGL ドライバーでのクラッシュです。

于 2013-09-28T18:49:09.277 に答える