多くのメモリ割り当てを行うかなり複雑なプログラムを持っていますが、今日、驚いたことに、gdb が場所を特定できない奇妙な方法でセグメンテーション違反を開始しました。どこかでメモリの破損を疑って、Electric Fence にリンクしましたが、それが何を言っているのか困惑しています:
ElectricFence Exiting: mprotect() failed:
Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/strlen.S
#0 __strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen.S:99
#1 0xb7fd6f2d in ?? () from /usr/lib/libefence.so.0
#2 0xb7fd6fc2 in EF_Exit () from /usr/lib/libefence.so.0
#3 0xb7fd6b48 in ?? () from /usr/lib/libefence.so.0
#4 0xb7fd66c9 in memalign () from /usr/lib/libefence.so.0
#5 0xb7fd68ed in malloc () from /usr/lib/libefence.so.0
#6 <and above are frames in my program>
私は 36 の値で malloc を呼び出しているので、問題にはならないと確信しています。
私が理解していないのは、malloc でヒープを破棄する可能性さえあるということです。マニュアルページをもう少し読んでみると、フリーページに書いているか、バッファを引き受けているように見えます。そのため、次の環境変数を一緒に、または単独で試しました。
EF_PROTECT_FREE=1
EF_PROTECT_BELOW=1
EF_ALIGNMENT=64
EF_ALIGNMENT=4096
最後の 2 つはまったく効果がありませんでした。
最初のものは、私のプログラムにあるスタックフレームの部分を変更しました（私のプログラムでは、mallocが致命的に呼び出されたときに実行されていました）が、mallocが入力されると同じフレームになります。
2 番目のものはもう少し変更されました。私のプログラムの別の場所で発生したクラッシュに加えて、malloc ではなく realloc の呼び出しでも発生しましたが、realloc は直接 malloc を呼び出しており、それ以外のバック トレースは上記と同じです。
フェンス以外の他のライブラリに対して明示的にリンクしていません。
更新: 「mprotect() が失敗しました: メモリを割り当てることができません」というメッセージが、マシンに十分なメモリがないことを意味することを示唆する場所をいくつか見つけました。しかし、「メモリを割り当てることができません」という部分は表示されず、ps はメモリの 15% しか使用していないと言っています。このような小さな割り当て (4k+32) では、これが本当に問題になるのでしょうか?