問題タブ [electric-fence]

マルチスレッド (pthread ベース) プロジェクトに取り組んでいます。このプロジェクトでは、私が書いているライブラリを使用しています。

それを確認するためにリンクすると-lefence、SIGSEGVが得られました。何が問題なのかを理解するのに多くの時間を費やした後、機能が非常に単純であっても、最終的にライブラリでエラーを検索することにしました。

テストとして、テストユニットをリンクしてコンパイルしようとしましたが、-lefenceSIGSEGV を取得しました。テストは、異なるテストユニットで成功したコードを除いて、動的に割り当てられたメモリをいじっていません。

-pthreadまた、フラグがメモリ割り当てをラップとして設定していることにも気付きました。gcc -dumpspecs | grep pthread以下を生成します。

libefence がマルチスレッドをサポートしていない可能性はありますか?

編集:基本的に、電気フェンス ライブラリが通常の libc の malloc/free 呼び出しを置き換えると仮定しています。それらがスレッドセーフなフードでラップされているという事実は、再入不可のもので再びラップされているため、役に立ちません。

私は自分のより大きなプログラムの問題を実証するためにテストケースプログラムを書いてきましたが、テストケースには元のプログラムにはないバグがあります。

ヘッダーファイルは次のとおりです。

実装ファイルは次のとおりです。

このプログラムを電気柵にリンクすると、実行すると次のエラーで中止されます。

gdbからのバックトレースは、不正な命令がコンパイラによって生成されたのデストラクタにあることを示していPathfinderます。これは、shared_ptrの破棄に問題があります。誰もがそれがなぜであるかわかりますか？

トリッキーなメモリ破損バグ (メモリがランダムに上書きされる) を診断するために、Electric Fence といくつかのカスタム mprotect 呼び出しを利用して、破損したデータ構造に書き込みたい場合にのみ書き込み可能にすることを考えました (そしてすぐに取得します)。書き込みが試みられたときの SIGSEGV)。

残念ながら、上記のコードは Ruby C 拡張機能であるため、libefence の下で Ruby インタープリター全体を実行する際に libefence の下で実行することはパフォーマンス上の悪夢となります。

恐ろしく遅いです。

OTOH、ルビー拡張機能を libefence に直接リンクしても (リンカーに -lefence を渡すことによって)、libefence のインスツルメンテーションなしで実行する効果はないようです。

libefence を介して特定の共有ライブラリで発生するメモリ割り当てのみを実行し、他の共有ライブラリとメイン プロセスをそのままにしておく方法はありますか?

segfault で終了するプログラムをデバッグする場合、gdb と組み合わせて電気柵を使用すると、次のように返されます。

"ElectricFence Exiting: mprotect() failed: Cannot allocate memory [Thread 0xb0bd4b70 (LWP 5363) exited] Program exited with code 0377.

本当は電気柵の方が便利だと思っていました。これは何を意味するのでしょうか？この情報をどのように解釈できますか? 私が見ることができる、または少なくともbt何も返さないスタックが残っていないようです。

どんな提案でも大歓迎です。

ありがとう！

最近、ヒープの破損を伴う最初の戦い (解決済み)に遭遇しました。自宅の Linux マシンでは、valgrind と electric-fence (gdb を使用) を使用して、犯人コードがエラーなしで終了します。しかし、私たちの研究室の Windows マシンでは、参照した投稿で説明されているように、VS から一貫してヒープの破損に関連するエラー メッセージが表示されます。

valgrind と電気柵がそのような問題を検出しないのは驚くべき (または少なくとも珍しいこと) でしょうか? 他の誰かが、こちらの回答でvalgrindを逃した可能性のある同様のバグについて言及しました。これらのツールでこの問題が検出されない理由は何ですか? エラーが実際にヒープの破損であることを疑う理由はありますか?

更新:元の問題を説明した投稿で述べたように、問題は std::vector 内の要素へのポインターが原因であることがわかりました。これは悪くなりました。ベクトルを std::list (新しい要素を追加してもポインターが無効にならない) に置き換えると、問題が修正されました。valgrind が問題を検出しなかった理由についての私の質問に戻りますが、今後同様の状況、つまり valgrind によって検出されないメモリの問題を回避する方法についての推奨事項があるかどうかを尋ねます。お気に入りのツール。STL がどのように機能するかをよりよく理解することは、明らかに良い考えです。おそらく、プログラミングなどで assert を使用してより積極的になる必要があります。

最近、Electric Fence を試していますが、C++ コードでの使用方法がわかりません。

次に例を示します。

でコンパイルしました

また、最初に Electric Fence バナーが表示されず、実行可能ファイルに EF シンボルが見つかりません (nm コマンドを使用)。

しかし、プログラムを次のように変更すると:

すべてが良好です-EFが表示されます。私はそれが問題をちょっと解決することを知っています、私は知っています:)。そもそもなぜ機能しなかったのかを理解しnew()たいmalloc()だけdelete()ですfree()。

私がこれに参加した理由は、boostライブラリやその他のいくつかを使用する大きなプロジェクトです。そして、このプログラムはmalloc()orfree()を直接呼び出すことはありません。そして、EFでビルドするときは、EFを最終的な実行可能ファイルにリンクするだけでなく、EFをそれらにリンクしようとするすべてのライブラリを再構築しました。そして、どちらにもEFシンボルが見つかりません。それは正しいアプローチですか？それとも間違っていて、最終的にEFのみを実行可能ファイルにリンクする必要があり、ライブラリはそのままにしておく必要がありますか? しかし、実行可能ファイルに EF シンボルが見つかりません。

多くのメモリ割り当てを行うかなり複雑なプログラムを持っていますが、今日、驚いたことに、gdb が場所を特定できない奇妙な方法でセグメンテーション違反を開始しました。どこかでメモリの破損を疑って、Electric Fence にリンクしましたが、それが何を言っているのか困惑しています:

私は 36 の値で malloc を呼び出しているので、問題にはならないと確信しています。

私が理解していないのは、malloc でヒープを破棄する可能性さえあるということです。マニュアルページをもう少し読んでみると、フリーページに書いているか、バッファを引き受けているように見えます。そのため、次の環境変数を一緒に、または単独で試しました。

最後の 2 つはまったく効果がありませんでした。

最初のものは、私のプログラムにあるスタックフレームの部分を変更しました（私のプログラムでは、mallocが致命的に呼び出されたときに実行されていました）が、mallocが入力されると同じフレームになります。

2 番目のものはもう少し変更されました。私のプログラムの別の場所で発生したクラッシュに加えて、malloc ではなく realloc の呼び出しでも発生しましたが、realloc は直接 malloc を呼び出しており、それ以外のバック トレースは上記と同じです。

フェンス以外の他のライブラリに対して明示的にリンクしていません。

更新: 「mprotect() が失敗しました: メモリを割り当てることができません」というメッセージが、マシンに十分なメモリがないことを意味することを示唆する場所をいくつか見つけました。しかし、「メモリを割り当てることができません」という部分は表示されず、ps はメモリの 15% しか使用していないと言っています。このような小さな割り当て (4k+32) では、これが本当に問題になるのでしょうか?

電気柵を使用して、私のプログラムでいくつかのメモリエラーを見つけようとしています。私のプログラムは OpenMPI を使用しており、それを実行しようとすると、次のバック トレースでセグメンテーション違反が発生します。

私のコードの関連部分は次のとおりです。

__memcpy_ssse3_back がセグメンテーション違反を引き起こしている理由がわかりません。プログラムのこの部分は、電気柵なしで実行してもセグメンテーション フォールトしません。誰が何が起こっているのか知っていますか？私はopenmpiバージョン1.4.3を使用しています

私はバグのあるプログラムを作成しました - buggy.c - これはバッファ t のバッファ オーバーフロー シナリオです。5 つ以上のインデックスを書いていることがわかります。それは正常に動作します。エラーが発生することはありません。ふと思ったのですが、どうしてこうなったのでしょう？Valgrindでも試しましたが、これもこの問題を見つけることができませんでした。ここで何が問題なのか教えてください。

ただし、クラッシュは発生しません。ここでは電気柵の効果はありません。私は何が欠けていますか？ここに投稿された同様の質問を見ましたgcc with electric fence library does not take effectですが、まだ回答がないようです。この例を FC19 で実行しています。誰もそれに対する答えを持っていますか？valgrind でさえ問題を検出できませんか? これらの問題を検出する他のツールはありますか?

さらなるコメントに基づいて、Electric Fence によって検出されるようにバッファ オーバーフロー関数を修正しました。ただし、Electric Fence は問題を検出できません。これが変更された関数です。

Electric Fence では検出されたエラーはありませんが、Valgrind では少なくともエラーが表示されました。