Hunting Heap Overflows
Unfortunately, software bugs are ubiquitous in computing. A very common flaw in a program is to access a memory area not under its control, usually resulting in a crash. To fix the problem, you first have to find the statement in your code that leads to the illegal access. Since this is not always the same spot where the program ultimately crashed, this is not a trivial task. A memory debugger like Electric Fence facilitates it.
As the name suggests, Electric Fence creates a virtual high voltage boundary around your programs. In more technical terms this means that every call to one of the memory management functions of the standard C library (i.e. malloc and friends) results in not only the requested area being allocated but also a second area immediately after the first one. The second area is marked as inaccessible, so that every read or write access causes a segmentation fault. This catches buffer overflows even if they consist only of a single byte. The only exception to this is when the size of the allocated buffer is not a multiple of the word size of the system. Then a small misalignment is unavoidable and an overflow of only a few bytes cannot be detected.
If you are interested in buffer underflows (i.e. access to regions before the allocated area) you can configure Electric Fence to place the inaccessible area before your buffer. In a similar way, this works for memory areas that have already been freed but are being accessed afterwards.
So now you know how Electric Fence works in theory but how can you integrate it into your programs? Well, simply link against the libefence library and run your program in your favorite debugger. If Electric Fence triggers a crash, the debugger will point at the very instruction that caused the illegal memory access.
Configuration is typically done via environment variables — this is documented in the efence(3) manual page. Options include the alignment and some fine-tuning of the behavior of various functions provided by the library. Rather unpleasant is that the manpage praises Purify, a proprietary memory debugger, in a section entitled "What's Better". Since this was written by Bruce Perens, maybe Richard Stallman isn't so wrong in his open source vs. free software argument.
Even though the purpose of Electric Fence is to get rid of the dreaded buffer overflows, this has to be taken with a grain of salt. In most cases, it is not possible to use it for protection against security holes introduced by buffer overflows. These are often triggered only by specially crafted input data, so no overflow under normal conditions does not imply there is no bug when dealing with more exotic inputs. In addition to this, Electric Fence only catches heap overflows — memory allocated on the stack, e.g. by a statement like char buf;, cannot be debugged. This would have been especially useful as stack overflows often overwrite return addresses, making debugging with conventional methods extremely difficult.
Altogether, the ease of use makes Electric Fence ideal as a first shot when you run into trouble with your memory management. If that doesn't help, another tool like Valgrind is needed.