4

次のようなオブジェクトでセグメント エラーが発生しました。

http_client_reset(struct http_client *client) {
    if (client->last_req) {
         /* @client should never be NULL, but weather
            a valid object, I don't know */
        ...
    }
}

GDB のコア ダンプ ファイルをデバッグすると、のメモリ アドレスclientは0x40a651c0. 何度か試しましたが、アドレスは同じです。

bt次に、GDBでコマンドを試しました：

(gdb) bt
#0  0x0804c80e in http_client_reset (
    c=<error reading variable: Cannot access memory at address 0x40a651c0>, 
    c@entry=<error reading variable: Cannot access memory at address 0x40a651bc>)
    at http/client.c:170
Cannot access memory at address 0x40a651bc

バック トレース メッセージはありませんgrep。ソース コードを編集しましたhttp_client_reset。

  • メモリアドレスのみを介してこのようなバグをデバッグするにはどうすればよいですか?
  • フィールドにアクセスする前にオブジェクトが有効であると判断する方法はありますか (を除くobj == NULL)?
4

1 に答える 1

-1

コアダンプ クラッシュのデバッグは「白黒」の問題ではありません。そのため、コアダンプのデバッグに関する質問に対して正確な回答を得ることはできません。ただし、ほとんどのコアダンプはプログラミング エラーによるもので、さまざまな領域に分類できます。これらの広範な領域とデバッグ メカニズムのいくつかを提供します。これは役立つかもしれません。

クラッシュにつながるプログラミング エラーのクラス

  1. マルチスレッド コード- 共通データへのアクセス中にクリティカル セクションの欠落をチェックします。これにより、このようなクラッシュにつながるデータが破損する可能性があります。あなたの場合、http_client ポインター、これへのアクセス、およびCRUD作成/読み取り/更新と削除を確認できます。
  2. ヒープの破損- ほとんどの場合、これは有効なポインターであり、コードの別のセクションでのヒープの不適切な処理が原因で、有効なポインターが上書きされる可能性があります。ポインターの位置とその周辺の配列を考えてみてください。ABW などの問題は、この問題を簡単に引き起こします。
  3. スタックの破損- これはほとんどありませんが、見つけるのは困難です。スタック データ (上記の例の配列と同様) を上書きする場合、スタック上で同じ問題が発生します。

コアダンプの根本原因を突き止める方法

理解する必要があります-技術的には、コアダンプは不正な操作であり、クラッシュにつながる未処理の例外を引き起こします。そのほとんどはメモリ処理に関連しているため、静的分析ツールなどを使用kloc/PCLintすると、問題のほぼ 80% を捕捉できます。それから私は次に実行しvalgrind/purify、おそらく残りの問題を明らかにするでしょう. それらの両方を見逃す問題はほとんどありません。これは、シーケンス/タイミング関連のコードであり、 で見つけることができますcode review。

チッ！

于 2013-08-12T10:32:00.533 に答える