1

gdbで分析されたコアダンプから次の逆アセンブルされたコードがあります。

   0x083dc366 <+194>:   call   0x83db38e <Buf::push_data(UBYTE const*, UWORD)>  
=> 0x083dc36b <+199>:   mov    eax,esi  
   0x083dc36d <+201>:   mov    edx,DWORD PTR [ebp-0x1c]

最初のmov命令でクラッシュする可能性はありますか、それともgdbからの小さな矢印は信頼されませんか？

4

3 に答える 3

3

その特定の命令でクラッシュする可能性がある唯一の方法は、メモリが実行可能でない場合です (たとえば、たまたま としてデコードされたデータ バイトにジャンプするmov)。適切なコード セクションからのように見えるため、この場合はありそうにありません。

GDB は、関数呼び出しが返され、呼び出された関数内で実際のクラッシュが発生した場所を示しているだけだと思います。関数のコードにアクセスできないか、別の理由でスタック フレームを切り替えることにした可能性があります。を使用して完全なスタック トレースを検査し、bt必要に応じて を使用してフレームを切り替えframe #nます。

極端な場合、ダンプ自体が破損しており、不適切な情報が含まれている可能性があります。クラッシュを確実に再現できる場合は、最初から GDB でプログラムを実行し、何かが破損する前にクラッシュが発生したときにそれをキャッチすることをお勧めします。

于 2013-03-05T17:16:53.467 に答える
1

最初の mov 命令でクラッシュする可能性はありますか

いいえ。

または、gdb からの小さな矢印は信頼できません

矢は信頼されるべきです。

「意味のない」データを持っている可能性が最も高い理由: 実行可能ファイルを再構築したか、GDB に間違った実行可能ファイルを与えたため、クラッシュした実行可能ファイルには、GDB を指した実行可能ファイルとは異なる命令がありました。0x083dc36b

于 2013-03-05T17:17:33.330 に答える
1

番号。

レジスタはメモリに格納されていませんが、CPU には特別な場所があるため、2 つのレジスタ間の移動によってセグメンテーション フォールトが発生することはありません。gdb の矢印は現在の行を示していません。命令ポインターの現在の値、または実行される次の命令を示していますが、前の行がまだ実行されていない可能性があるため、クラッシュの原因である可能性があります。

于 2013-03-05T17:12:12.310 に答える