When memory is allocated from the heap, the memory management functions need someplace to store information about the allocations. That place is the heap itself; this means that the heap is composed of alternating areas of memory that are used by the program and by the memory management functions themselves. This means that buffer overflows or underruns can actually damage the data structures that the memory management functions use to keep track of what memory has been allocated. When this happens, all bets are off, except that it is a pretty good bet that the memory management functions will eventually cause the program to crash.

If you set the MALLOC_CHECK_ environment variable, a different and some-what slower set of memory management functions is chosen that is more tolerant of errors and can check for calling free() more than once on the same pointer and for single-byte buffer overflows. If MALLOC_CHECK_ is set to 0, the memory management functions are simply more tolerant of error but do not give warnings. If MALLOC_CHECK_ is set to 1, the memory management functions print out warning messages on standard error when they notice problems. If MALLOC_CHECK_ is set to 2, the memory management functions call abort() when they notice problems.

Setting MALLOC_CHECK_ to 0 may be useful if you are prevented from finding one memory bug by another that is not convenient to fix at the moment; it might allow you to use other tools to chase down the other memory bug. It may also be useful if you are running code that works on another system but not on Linux and you want a quick workaround that may allow the code to function temporarily, before you have a chance to resolve the error.

Setting MALLOC_CHECK_ to 1 is useful if you are not aware of any problems and just want to be notified if any problems exist.

Setting MALLOC_CHECK_ to 2 is most useful from inside the debugger, because it allows you to get a backtrace as soon as the memory management functions discover the error, which will get you closest to the point at which the error has happened.

$ MALLOC_CHECK_=1 ./broken
malloc: using debugging hooks
1: 12345
free(): invalid pointer 0×80ac008!
2: 12345678
3: 12345678
4: 12345
5: 12345
6: 12345
7: 12345
$ MALLOC_CHECK_=2 gdb ./broken
...
(gdb) run
Starting program: /usr/src/lad/code/broken
1: 12345
Program received signal SIGABRT, Aborted.
0×00c64c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) where
#0  0×00c64c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0×00322969 in raise () from /lib/tls/libc.so.6
#2  0×00324322 in abort () from /lib/tls/libc.so.6
#3  0×0036d9af in free_check () from /lib/tls/libc.so.6
#4  0×0036afa5 in free () from /lib/tls/libc.so.6
#5  0×0804842b in broken () at broken.c:17
#6  0×08048520 in main () at broken.c:47

Another way to ask glibc to do heap consistency checking is with the mcheck() function:

typedef void (*mcheckCallback)(enum mcheck_status status);
void mcheck(mcheckCallback cb);

When the mcheck() function has been called, malloc() places known byte sequences before and after the returned memory region in order to make it possible to spot buffer overflow and buffer underrun conditions. free() looks for those signatures, and if they have been disturbed, it calls the function pointed to by the cb parameter. If cb is NULL, the library exits instead. Running a program linked against mcheck() through gdb can show you exactly which memory regions have been corrupted, as long as those regions are properly free() ed. However, the mcheck() method does not pinpoint exactly where the corruption occurred; it is up to the programmer to figure that out based on an understanding of the program flow.

Linking our test program against the mcheck library yields the following results:

$ gcc -ggdb -o broken broken.c -lmcheck
$ ./broken
1: 12345
memory clobbered past end of allocated block

Because mcheck merely complains and exits, this does not really pinpoint the error. To pinpoint the error, you need to run the program inside gdb and tell mcheck to abort() when it notices a problem. You can simply call mcheck() from within gdb, or you can call mcheck(1) as the first line of your program (before you ever call malloc()). (Note that you can call mcheck() from within gdb without linking your program against the mcheck library!)

$ rm -f broken; make broken
$ gdb broken
...
(gdb) break main
Breakpoint 1 at 0×80483f4: file broken.c, line 14.
(gdb) command 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>call mcheck(&abort)
>continue
>end
(gdb) run
Starting program: /usr/src/lad/code/broken
Breakpoint 1, main () at broken.c:14
47          return broken();
$1 = 0
1: 12345
Program received signal SIGABRT, Aborted.
0×00e12c32 in_dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) where
#0  0×00e12c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0×0072c969 in raise () from /lib/tls/libc.so.6
#2  0×0072e322 in abort () from /lib/tls/libc.so.6
#3  0×007792c4 in freehook () from /lib/tls/libc.so.6
#4  0×00774fa5 in free () from /lib/tls/libc.so.6
#5  0×0804842b in broken () at broken.c:17
#6  0×08048520 in main () at broken.c:47

The important part of this is where it tells you that the problem was detected in broken.c at line 17. That lets you see that the error was detected during the first free() call, which indicates the problem was in (or more precisely, bordering) the dyn memory region. (freehook() is just the hook that mcheck uses to do its consistency checks.)

mcheck does not help you to find overflows or underruns in local or global variables, only in malloc() ed memory regions.

A simple way to find all of a program’s memory leaks is to log all its calls to malloc() and free(). When the program has completed, it is straightforward to match each malloc() ed block with the point at which it was free() ed, or report a leak if it was never free() ed.

Unlike mcheck(), mtrace() has no library against which you can link to enable mtrace(). This is no great loss; you can use the same technique with gdb to start tracing. However, for mtrace() to enable tracing, the environment variable MALLOC_TRACE must be set to a valid filename; either an existing file that the process can write to (in which case it is truncated) or a filename that the process can create and write to.

$ MALLOC_TRACE=mtrace.log gdb broken
...
(gdb) break main
Breakpoint 1 at 0×80483f4: file broken.c, line 14.
(gdb) command 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>call mtrace()
>continue
>end
(gdb) run
Starting program: /usr/src/lad/code/broken
Breakpoint 1, main () at broken.c:47
47          return broken();
$1 = 0
1: 12345
2: 12345678
3: 12345678
4: 12345
5: 12345
6: 12345
7: 12345
Program exited normally.
(gdb) quit
$ ls -l mtrace.log
-rw-rw-r--   1 ewt      ewt           220 Dec 27 23:41 mtrace.log
$ mtrace ./broken mtrace.log
Memory not freed:
-----------------
   Address     Size     Caller
0×09211378      0×5  at /usr/src/lad/code/broken.c:20

Note that the mtrace program has found the memory leak exactly. The mtrace program can also find memory that is free() ed that was never allocated in the first place if this case shows up in the log file, but in practice it will not find it there because the program should crash immediately when attempting to free() the unallocated memory.

One of the nicest things about Electric Fence is that it is easy to use. Simply link a program against libefence.a by running the final link step with -lefence as the final argument, and the code is ready to be debugged. Let’s see what happens when we run our test program against Electric Fence:

$ ./broken
  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens.
1: 12345
Segmentation fault (core dumped)

Although Electric Fence does not tell us exactly where the problem occurred, it does make the problem itself much more obvious. Pinpointing where the problem occurred is easily done by running the program under a debugger, such as gdb. To use gdb to pinpoint the problem, build the program with debugging information by using gcc’s -g flag, run gdb and tell it the name of the executable to debug, and run the program. When the program is killed, gdb shows you exactly what line caused the problem. Here is what this procedure looks like:

$ gcc -ggdb -Wall -o broken broken.c -lefence
$ gdb broken
...
(gdb) run
Starting program: /usr/src/lad/code/broken
  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens.
1: 12345
Program received signal SIGSEGV, Segmentation fault.
0x007948c6 in strcpy () from /lib/tls/libc.so.6
(gdb) where
#0  0x007948c6 in strcpy () from /lib/tls/libc.so.6
#1  0x08048566 in broken () at broken.c:21
#2  0x08048638 in main () at broken.c:47
(gdb)

Thanks to Electric Fence and gdb, we know there is a problem in file broken.c code at line 21, which is the second time strcpy() is called.

While Electric Fence did a fine job of finding the second problem in the code—namely, the strcpy() that overwrote its buffer by a large amount—it did not help us at all in finding the first buffer overflow.

The problem here has to do with memory alignment. Most modern CPUs require multibyte objects to start at particular offsets in the system’s RAM. For example, Alpha processors require that an 8-byte long begin at an address that is evenly divisible by eight. This means that a long may appear at address 0x1000 or 0x1008, but not at 0x1005.^[8]

Because of this consideration, malloc() implementations normally return memory whose first byte is aligned on the processor’s word size (4 bytes on 32-bit processors and 8 bytes on 64-bit processors) to ensure the caller can store whatever data it likes into the memory. By default, Electric Fence attempts to mimic this behavior by providing a malloc() that returns only addresses that are an even multiple of sizeof(int).

In most programs, such alignment is not all that important, because memory allocations are done in increments that are already based on the machine’s word size, or of simple character strings, which do not have any alignment requirements (as each element is only one byte long).

In the case of our test program, the first malloc() call allocated five bytes. For Electric Fence to meet its alignment restrictions, it must treat the allocation as a request for eight bytes and set up the memory with an extra three bytes of accessible space after the malloc() ed region! Small buffer overflows in this region are not caught because of this.

As malloc() alignment concerns can normally be ignored and the alignment can allow buffer overflows to remain undetected, Electric Fence lets you control how alignment works through the EF_ALIGNMENT environment variable. If it is set, all malloc() results are aligned according to its value. For example, if it is set to 5, all malloc() results will be addresses evenly divisible by 5 (this probably is not a very useful value, however). To turn off memory alignment, set EF_ALIGNMENT to 1 before running your program. Under Linux, improperly aligned accesses are fixed in the kernel anyway, so although this may slow your program down substantially, it should function properly—unless it has slight buffer overflows!

Here is how our test program linked against Electric Fence behaved when we set EF_ALIGNMENT to 1:

$ export EF_ALIGNMENT=1
$ gdb broken
...
(gdb) run
Starting program: /usr/src/lad/code/broken
  Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens.
Program received signal SIGSEGV, Segmentation fault.
0x002a78c6 in strcpy () from /lib/tls/libc.so.6
(gdb) where
#0  0x002a78c6 in strcpy () from /lib/tls/libc.so.6
#1  0x08048522 in broken () at broken.c:15
#2  0x08048638 in main () at broken.c:47

This time it found the first buffer overflow that occurred.

Not only does Electric Fence help detect buffer overflows, but it also can detect buffer underruns (accessing the memory before the start of a malloc() ed buffer) and accesses to memory that has already been free() ed. If the EF_PROTECT_BELOW environment variable is set to 1, Electric Fence traps buffer underruns instead of overflows. It does this by placing an inaccessible memory region immediately before the valid memory region returned by malloc(). When it does this, it can no longer detect overflows because of the memory paging layout of most processors. The memory alignment concerns that make overflows tricky do not affect underruns, however, as in this mode, Electric Fence’s malloc() always returns a memory address at the beginning of a page, which is always aligned on a word boundary.

If EF_PROTECT_FREE is set to 1, free() makes the memory region passed to it inaccessible rather than return it to the free memory pool. If the program tries to access that memory at any point in the future, the kernel will detect the illegal access. Setting EF_PROTECT_FREE makes it easy to ensure that your code is not using free() ed memory at any point.

While Electric Fence does a nice job of finding overflows of malloc() ed buffers, it does not help at all with tracking down problems with either global or locally allocated data. It also does not make any attempt to find memory leaks, so you have to look elsewhere for help with those problems.

Although Electric Fence is powerful, easy to use, and fast (because all the access checks are done in hardware), it does exact a price. Most processors allow the system to control access to memory only in units of a page at a time. On Intel 80x86 processors, for example, each page is 4,096 bytes in size. Because Electric Fence wants malloc() to set up two different regions for each call (one allowing access, the other allowing no access), each call to malloc() consumes a page of memory, or 4K!^[9] If the code being tested allocates a lot of small areas, linking the code against Electric Fence can easily increase the program’s memory usage by two or three orders of magnitude! Of course, using EF_PROTECT_FREE makes this even worse because that memory is never freed.

For systems with lots of memory relative to the size of the program you are debugging, when you are looking to find the source of a specific instance of corruption, Electric Fence may be faster than Valgrind. However, if you need to enable a gigabyte of swap space just to make Electric Fence work, then Valgrind will probably be much faster even though it is using a CPU emulator instead of the native CPU.