malloc を使用しているときに、次のエラーでコア ダンプが生成される場合:
malloc(): memory corruption: ....... ***
これは、malloc が自由に割り当てられないメモリを割り当てようとしたことを意味しますか? もしそうなら、これの原因は何ですか?
それは完全に malloc の実装に依存しますが、通常これは、その malloc の前のある時点で、何かがそのサイズよりも多くのデータを malloc バッファーに書き込んだことを意味します。
多くの malloc 実装は、データの一部をメモリにインラインで格納します。つまり、次のようになります。
+--------------------------------+
|14 bytes -> Padding |
+--------------------------------+
|2 bytes -> Internal malloc info |
+--------------------------------+
|6 bytes -> Your data |
+--------------------------------+
|8 bytes -> Padding |
+--------------------------------+
|2 bytes -> Internal malloc info |
+--------------------------------+
したがって、あなたのコードまたはライブラリがその 6 バイト バッファに 16 バイトを書き込んだ場合、パディングと 2 バイトの内部 malloc 情報が上書きされます。次に malloc を呼び出すと、そのデータを調べてスペースを見つけようとし、上書きされたスペースにヒットします。上書きしたため無意味になり、ヒープが破損します。
実装によっては、このようなエラーは double を解放することによっても発生する可能性があります。
ほとんどの場合、これは malloc 自体の問題ではありません。むしろ、これはアプリケーションが変更すべきではないヒープの部分を変更する際の問題です。
Linux で実行している場合は、Valgrindを使用して、ヒープを破棄しているコードを確認してください。
これの通常の原因は、malloc() が上書きの許可を与えなかったデータを上書きしたことです。バッファ オーバーラン (指定されたスペースの末尾を超えて書き込む) またはバッファ アンダーラン (バッファの開始前に書き込む) のいずれかです。 )。
malloc() などによって割り当てられなかったポインターを解放したり、malloc() によって割り当てられたポインターを再度解放 (二重解放) したりすることによって発生することがあります。たとえば、静的バッファを解放するのは悪い考えです。あなたは腐敗します。
問題はコードにあると想定する必要があります。malloc() などで問題になる可能性は非常に低く、使用している他のライブラリに問題がある可能性はほとんどありません。
ヒープ破損の一般的な原因として、次のようなことがいくつかあります。
これらの問題は、原因と結果が時間と空間 (コードの異なる領域) で分離されていることが多いため、デバッグが困難な場合があります。したがって、問題の原因となったバグが実行されてから (コンピュータ時間で) 永遠が経過するまで、バグは気付かれません。
デバッグ ヒープを使用すると、これらの問題のデバッグに非常に役立ちます。Microsoft のコンパイラには、デバッグ ビルドで有効なCrtDebug ヒープがあります (ただし、追加の構成項目を設定できます)。GCC にすぐに使える機能があるかどうかはわかりませんが、 Valgrind や Electric Fenceなど、私がよく知っているツールが役立つかもしれません。最後に、役に立つかもしれない自作のヒープ デバッグ ライブラリがたくさんあります (Google 周り)。
malloc() ステートメントを教えてください。
また、戻り値がnullでないことを再確認したかったのですか?
malloc()
最初に割り当てるメモリがないこと以外に、実際に破損したヒープの結果である、new
あなたが言及した性質を使用したときに発生した問題。私は通常、プログラムの他の場所で、バッファー オーバーランとマングルされたアドレス空間を引き起こす文字バッファーで memcpy() のような何かをしている「興味深い」コードを見つけました。
-億