Understanding the output of electric fence and gdb

Question

When debugging a program that terminates with a segfault, electric fence, in conjunction with gdb, returns this:

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

I actually thought electric fence would be more helpful. What does this mean? How can I interpret this piece of information? There doesn't seem to be any stack left that I can look at, or at least bt won't return anything.

Any suggestion would be really appreciated.

Thanks!

Romantic

Also, when I debug the program, it doesn't look like it's consuming all the memory... there's still ~1GB left, that is half of it. So I shouldn't even be concerned with swap space, right? – Romantic

Answer 1

You have probably run out of memory map areas. The default is known to be low when using debug allocators. This can be adjusted at runtime via

echo 128000 > /proc/sys/vm/max_map_count

or by adding this line to /etc/sysctl.conf and rebooting:

vm.max_map_count = 128000

The max_map_count number defaults to 65530 and can be increased as high as MAX_INT if necessary.

For more information see:

• max_map_count
• Side effects when increasing vm.max_map_count

Exterritorial

Answer 2

The output of ElectricFence simply means that it ran out of memory and can't help you.

ElectricFence imposes extremely high memory overhead, especially for programs with lots of small heap allocations.

If you are on Linux, try Valgrind instead.

Also note, that your first step for a program that dies with SIGSEGV should not be running it with ElectricFence; rather you should run the program under debugger and see where it crashes.

Ephraim

Hmm... I have still a lot of memory available when it returns that message. Could it be just about to use it all at once? That's strange. – Romantic

So, anyway, when exactly should I use electric fence, if not in this case? – Romantic