1

だから私は今、奇妙なエラーに数回遭遇し、問題を特定するためのいくつかの良い方向を探しています。

基本的に私が見ているのはセグメンテーション違反です。症状は次のとおりです。

  1. これは、プログラムがデバッグではなくリリースモードの場合にのみ発生します。

  2. これはセグメンテーション違反として表示され、GDBは関数の最後にある//にあることを通知_list_releaseし_free()ますfree()。

    Program received signal SIGSEGV, Segmentation fault.

    0xb0328af8 in _list_release () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

    (gdb) bt

    0 0xb0328af8 in _list_release () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

    1 0xb032a464 in __free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

    2 0xb0329f7d in free () from /usr/qnx650/target/qnx6/x86/lib/libc.so.3

  3. 動的メモリを使用していません（Eigen（または他のライブラリ）に表示される可能性があるものを除く）

  4. 関数の終わりの直前にすべてのローカル変数を出力できるので、ダブルフリーではありません。

前回これが起こったのは、これらすべての問題に当てはまるメモリ障害でした。迷惑な今回は問題が見つかりません。

私がやりたいことは次のとおりです。

  1. これは非常に便利です。デバッグモードでこのエラーを強制するにはどうすればよいですか。そうすれば、GDBの方がはるかに役立ちます。
  2. 小さなバガーが問題を引き起こしているものを追跡するための最良の方法は何ですか。注： valgrindは使用できません。使用しているオペレーティングシステムでは機能しません（QNX）

どんな助けでも素晴らしいでしょう。

4

1 に答える 1

4

セグメンテーション違反として表示され、GDBはそれが_list_release / _free（）/ free（）にあることを通知します

一般に、クラッシュはfree()ヒープの破損の兆候です（二重解放、解放されたメモリへの書き込み、未割り当て（スタックやグローバルなど）のメモリの解放、またはヒープバッファのオーバーフロー）。

動的メモリを使用していません

はい、あなたはです。他のライブラリを介して間接的にそうするという事実は関係ありません。

関数の終わりの直前にすべてのローカル変数を出力できるので、ダブルフリーではありません。

多くのコメント提供者がすでに述べているように、あなたの結論は続きません。解放されたメモリに問題なくアクセスでき、それでも賢明な値が含まれている可能性があります。

デバッグモードでこのエラーを強制するにはどうすればよいですか。GDBの方がはるかに役立ちます。

  • '-O2 -g'（「リリース」モードですが、デバッグ情報が有効になっている）でビルドできます。
  • GDBはおそらくこれ以上役に立たないでしょう-GDBはヒープの破損をデバッグするのにいくらか役に立たないでしょう。

小さなバガーを追跡するための最良の方法は何ですか

いくつかの選択肢があります。

  • ValgrindまたはAddressSanitizerを使用できるプラットフォームにコードを移植します
  • 多くのデバッグmalloc実装（dmalloc、mpatrolなど）の1つを使用します。QNXには1つあります。
  • コードを注意深く読み、誤って割り当てられた可能性のあるバッファーに想定よりも多くのデータを書き込まないようにしてください。
于 2013-01-07T07:31:48.887 に答える