Electric Fence
Electric Fence (efence) stops your program on the exact instruction that overruns (or underruns) a malloc() memory buffer. GDB will then display the source-code line that causes the bug. It works by using the virtual-memory hardware to create a red-zone at the border of each buffer - touch that, and your program stops. Catch all of those formerly impossible-to-catch overrun bugs that have been bothering you for years.
| Tags | Software Development Debuggers Testing Libraries |
|---|---|
| Licenses | GPL |
| Operating Systems | POSIX Linux Unix Windows Windows Windows Cygwin |
| Implementation | C++ C |
Recent releases
- 30 Aug 2005 07:43
Changes: The main focus of this release is better portability. A standardized strerror() is now used. An error which occurred when EF_NO_LEAKDETECTION was defined was fixed. Allocations from standard libraries are marked before ef_init() is called to allow special treatment in leak-checking. The default in eftest was changed to use two signals at once: SIGSEGV and SIGBUS. Alignments bigger than page size are now allowed for memalign(). The EF_EXPLICIT_INIT preprocessor flag was added to work around buggy environments. Environment leaks are no longer reported.
- 24 Jul 2005 23:11
Changes: Bugs in page management under Windows where virtual address space was never released was fixed, though this fix avoids memory pooling (under Windows). An ExitOnFail parameter was added to Page_Create(). A warning is now displayed when an allocation failed and ExitOnFail is off. _eff_allocate() was extended for this.
- 15 Jul 2005 20:54
Changes: Bugfixes were made in memory management. New macros were provided for new and delete. Functions for doing extra checks were added for strdup(), memcpy(), strcpy(), strncpy(), strcat(), and strncat(). A new EF_SHOW_ALLOC environment switch was included.
- 12 Feb 2005 22:20
Changes: This release reworks and revises all internal functions. It adds an EF_OLD_NEW_MACRO preprocessor flag to keep compatibility to old NEW_ELEM() / NEW_ARRAY() macros. Freeing already freed memory is now detected. It stores __FILE__ and __LINE__ of free() to be able to print the position of first free. This version fixes a bug that occurred when calling eftest with a higher number e.g. 10000. There were bugfixes to memalign() which was not exported. Macros and functions are now also defined for valloc().
- 02 Feb 2005 20:58
Changes: A EF_NO_GLOBAL_MALLOC_FREE preprocessor flag was added to work around buggy environments. This prevents malloc(), free(), realloc(), and calloc() from being put into the global namespace of the efence library, thus only files which include efence.h will call the efence malloc() replacement functions. This flag is also helpful where the linking order cannot be controlled, for example when memory is allocated from a library not using efence, but free() is called from using efence. This is a problem when using .dll libraries linked against msvcrt.dll and its malloc/free under MS Windows.
- All comments
Recent commentsSuccessor DUMA
The successor of the 2.4.x versions (including the Windows port) is now called DUMA (http://freshmeat.net/projects/duma/) as it represents a fork of Bruce Perens'
Electric Fence (http://perens.com/FreeSoftware/ElectricFence/).
DUMA is also anounced on freshmeat:
http://freshmeat.net/projects/duma (http://freshmeat.net/projects/duma/).
improvements, port, ...
I took the latest version 2.2.2 of electric fence from Bruce Perens and:
- added support for MS Windows
- added some C++ support
- added leak detection
- improved/added much more ...
The development is not at its end:
- documentation (manpage) should get updated
- tutorials/faqs/introductions should get written
- some todo's are open (c++ behaviour of operators)
- some things may be broken (several IDE's)
But it's worth a look.
Please see http://www.pf-lug.de/projekte/haya/efence.php
or
Check out directly (when online) from CVS with
CVSROOT=':pserver:anonymous@ayguen.homeip.net:/home/samba-shares/CVS_EFENCE'
The CVS module name is 'efence'.
I'm awaiting your comments!
Re: Valgrind
Valgrind
was very helpful, but
it was way too verbose about things
going on in various
libraries that were not relevant. That
is, it gives LOTS of
false positives.
What makes you think those were false positives? Are you saying you know for sure all libraries you use are bug-free? Did you check up on any of the "false" positives, and verify that the Valgrind hits were indeed false?
Re: Valgrind
> If you want a more thorough tool for
> memory debugging I can warmly recommend
> Valgrind. It discovers everything
> Electric Fence does plus lots more (like
> accesses to free()d and uninitialized
> memory and memory leaks). All while
> being easier to use than Electric Fence.
> The downside is that it works only on
> Linux / x86 and your code will run maybe
> 10x slower than ordinary.
>
> I just ran it on Bubblemon, and I'm
> hooked ;-).
I disagree with this. I tried to find my memory error in my
program using valgrind first. Valgrind was very helpful, but
it was way too verbose about things going on in various
libraries that were not relevant. That is, it gives LOTS of
false positives. I linked with electric fence and found my
memory error (a reference to freed memory, contrary to
your claims) literally in five minutes.
Valgrind
If you want a more thorough tool for memory debugging I can warmly recommend Valgrind (http://freshmeat.net/projects/valgrind/). It discovers everything Electric Fence does plus lots more (like accesses to free()d and uninitialized memory and memory leaks). All while being easier to use than Electric Fence. The downside is that it works only on Linux / x86 and your code will run maybe 10x slower than ordinary.
I just ran it on Bubblemon (http://freshmeat.net/projects/bubblemon4gnome/), and I'm hooked ;-).