1

セグメンテーション違反が発生した後、gdba.outcoreコマンドを使用しました。その後、バックトレース（bt）を使用しました。これは、gdbが教えてくれることです。

警告：コアファイルが指定された実行可能ファイルと一致しない可能性があります。

警告：0xfbe8で共有ライブラリリストエントリの読み取り中にエラーが発生しました

警告：0x74c085ffで共有ライブラリリストエントリの読み取り中にエラーが発生しました

コアは「family.outsmith.ged」によって生成されました。

プログラムは信号11、セグメンテーション違反で終了しました。

（poundsign）0 0x08086a6 in count_records（）

（gdb）bt

（poundsign）0 0x080486a6 in count_records（）

（poundsign）1 0x08048906 in __libc_csu_init（）

（ポンド記号）2 0xbf85624c in ??（）

（ポンド記号）3 0xbf856310 in ?? （）

バックトレースが停止しました：このフレームの内側にある前のフレーム（スタックが破損していますか？）

誰かがこのセグメンテーション違反を引き起こした可能性があるものについての洞察を私に与えることができますか？通常、gdbはプログラムの行番号を教えてくれますが、今回はそうではありませんでした。

4

1 に答える 1

3

ここで発生する可能性が高いのは、スタックが破損していることです。プログラムの状態の多く（現在の関数を示すすべてのスタックフレームを含む）はスタックに存在するため、上書きされると、デバッガーには破損した情報しかありません。

これを行う一般的な方法は、ローカル変数として宣言されたバッファを文字列としてオーバーフローさせることです。

int main()
{
    char buf[4];
    return func1(buf);
}

int func1(char* theBuf)
{
    return func2(theBuf);
}

int func2(char* sameBufBackSomeplaceInTheStack)
{
     sprintf(sameBufBackSomeplaceInTheStack, "The stack is doomed.");
     return 0;
}

結果は異なる場合がありますが、これを実行した後、デバッガーで破棄されたスタックは次のようになります。

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000100000d00 in _mh_execute_header ()
(gdb) where
#0  0x0000000100000d00 in _mh_execute_header ()
#1  0x0000000000000000 in ?? ()
(gdb)

とにかく、どこかであなたのプログラムがスタックを上書きしました、それはしばしばデバッグするのが難しいです...

于 2013-02-26T05:11:38.297 に答える