malloc（）およびmalloc_consolidate（）のセグメンテーションフォールト
私のアプリケーションは、gdbのバックトレースを見ると、ときどき主にmalloc（）とmalloc_consolidate（）でセグメンテーション違反を起こします。
マシンに十分なメモリがあることを確認しました。スワップも開始されませんでした。データセグメントと最大メモリサイズのulimitを確認しましたが、どちらも「無制限」に設定されています。また、アプリケーションをvalgrindの下で実行したところ、メモリエラーは見つかりませんでした。
今、私は他に何がこれらのセグメンテーションフォールトを引き起こしているのか考えられなくなっています。何か案は ？
更新： 私はvalgrind（またはptrcheck）で何も見つけていないので、別のアプリケーションがlibcのメモリ構造を破壊しているか、プロセスごとに個別の構造があるのでしょうか？
http://www.gnu.org/s/libc/manual/html_node/Heap-Consistency-Checking.html#Heap-Consistency-Checking から：
Malloc、realloc、およびfreeの使用におけるバグをチェックして保護する別の可能性は、環境変数MALLOC_CHECK_を設定することです。 MALLOC_CHECK_が設定されている場合、同じ引数を使用したfreeの二重呼び出し、または1バイトのオーバーラン（off-by-oneバグ）などの単純なエラーに耐えられるように設計された特別な（あまり効率的でない）実装が使用されます。ただし、このようなエラーのすべてを防止できるわけではなく、メモリリークが発生する可能性があります。 MALLOC_CHECK_が0に設定されている場合、検出されたヒープの破損は無視されます。 1に設定すると、診断がstderrに出力されます。 2に設定すると、すぐに中止が呼び出されます。そうしないとクラッシュがずっと後に発生する可能性があり、問題の真の原因を追跡することが非常に難しいため、これは役立ちます。
ほとんどの場合、ヒープを破壊しています-つまり、割り当てたメモリの制限を超えて書き込みを行っているため、malloc()がヒープの管理に使用するデータ構造が上書きされています。これにより、malloc()が無効なアドレスにアクセスし、アプリケーションがクラッシュします。
メモリが不足してもmalloc()はクラッシュしません-単にNULLが返されます。 NULLをチェックしないとコードがクラッシュする可能性がありますが、クラッシュサイトはmalloc()にはありません。
Valgrindがエラーを報告しないのは少し奇妙ですが、デフォルトの「Memcheck」ツールが見逃す可能性のあるいくつかのエラーがあります。代わりに "Ptrcheck"ツール を使用してValgridを実行してみてください。