Next: , Previous: Frequently asked questions, Up: Top

Appendix K Related software

The mpatrol library was designed to solve most common heap-related problems, but there may be some cases where a different approach is needed, or a commercial package is required. I have attempted to provide an overview of the different types of malloc libraries and memory debuggers available below, along with a comprehensive list of related software.

The most basic type of heap debugging system simply requires the redefinition of malloc(), realloc() and free() (and related functions) with debugging versions that record the file and line number at which allocations occur. This might require modifications to the source code in order to call these new functions or it can be done through preprocessor macros which will require all source files using the memory allocation functions to be recompiled. Such a system will most likely live on top of the existing system malloc library, but will provide an additional layer with which to store more information for debugging purposes. MEM by Walter Bright is a good example of this type of library.

On many operating systems it is usually possible to write replacements for the normal memory allocation routines and place them in a library so that they can be linked in to override the system malloc library without requiring recompilation of any source files. Such malloc libraries must take control of the heap directly and so usually contain more features, including being able to track memory leaks and place fence posts around allocations. Dbmalloc by Conor P. Cahill and Dmalloc by Gray Watson are two of the most popular of these types of libraries since they are available on a wide range of platforms. Electric Fence by Bruce Perens also makes use of the memory protection facilities found in UNIX systems in order to force programs that access free or freed memory or read or write beyond the bounds of a memory allocation to crash at the point that the illegal memory access is made, rather than crashing at the next memory allocation.

For debugging all memory access errors (not just those on the heap) it is necessary to modify (instrument) the machine code that is to be run so that each individual load from memory and store to memory will be checked. One method of doing this is to modify the code produced by a compiler (such as is done by Checker written by Tristan Gingold) but this has the disadvantage of only working within the object files that have been produced by that compiler. It is also possible to modify the source code itself using source to source translation (such as is done by Parasoft Insure++) or instrument all accesses to memory in assembler source files (as performed by APurify written by Samuel Devulder). However, both of these methods suffer from the same drawback as compiler-generated instrumentation. Yet another alternative is to wait until link-time and then instrument the individual object files and libraries before they are linked into an executable file. This is effectively what Purify from Rational Software does, although Memory Advisor from PLATINUM Technology does roughly the same except that it disassembles the object files into a platform-independent format before instrumenting them.

Rather than modifying a program in order to add debugging code, it is sometimes possible to use a dedicated memory debugger in order to quickly catch any problems. ZeroFault from The Kernel Group debugs all memory-related operations in a program while it is running, whilst AProbe from OC Systems allows users to dynamically add probe modules at run-time in order to locate errors or perform profiling. If such a memory debugger is not available for your system, you may still be able to dynamically link a malloc library into your application at run-time if the operating system supports it. NJAMD by Mike Perry makes extensive use of this feature on some UNIX systems. On operating systems that do not support virtual memory but have hardware memory protection, it is sometimes possible to trap memory errors before they bring down the whole system. On the Amiga, Enforcer by Michael Sinz runs in the background and detects many common memory access errors in running applications, whilst on the Macintosh, QC by Onyx Technology provides roughly the same functionality.

A list of over ninety five different items of software which help in debugging dynamic memory allocation problems is given below1. They all provide some of the features that mpatrol contains and you may wish to use one of them to solve your problem if you have trouble using mpatrol. I have only ever used CSRI malloc, Dbmalloc, Dmalloc, Electric Fence and Mprof, so I can't vouch for any of the others, although if you have any recommendations feel free to let me know so I can add them to this list. In particular, there seems to be a shortage of such programs for Netware platforms. Note that there is a comparison of a few of the following programs at http://www.consistent.org/terran/memorycheck.shtml which might help illustrate the differences between the various tools.

However, before you try out any of the above software, there may already be a malloc library with debugging support on your system that might be suitable for solving your problem. For example, on Solaris the following libraries are available:

malloc(3c)
Trade-off between performance and efficiency.
malloc(3x)
Slower performance, space-efficient.
bsdmalloc(3x)
Better performance, space-inefficient.
mtmalloc(3t)
Thread-safe memory allocator.
mapmalloc(3x)
Uses mmap() instead of sbrk() to allocate heap space.
watchmalloc(3x)
Uses watch point areas to check for overflows.

On platforms with the GNU C library, such as Linux, there are several environment variables that can be used to enable various debugging features of malloc(), etc. There are also extra functions provided in the library which can be used to aid in debugging, and some shell scripts which can translate return addresses or locate unfreed memory allocations in the log files produced. Useful information on the debugging features available within the GNU C library is located at http://sdb.suse.de/sdb/en/html/aj_debug.html.

If you suspect that the debugging problem you are looking at is likely to be related to UNIX system calls then some systems come with the strace or truss commands which allow you to trace all of the system calls that a program makes when running. This can sometimes be invaluable in pinpointing the exact point at which a program fails, but as it only operates at the system call level, no information about individual memory allocations is available.

On Windows 2000 (and probably later releases of the operating system as well) there is a utility called pageheap which acts in a similar way to the mpatrol command in that it overrides the definitions of malloc() and related functions for any programs that it runs. It has a similar behaviour to the --page-alloc-upper option but has far less features. However, it could be very useful if you can't get mpatrol to work for you.

Footnotes

[1] This list can be considered to be a slightly more up to date version of Debugging Tools for Dynamic Storage Allocation and Memory Management (http://www.cs.colorado.edu/~zorn/MallocDebug.html) by Ben Zorn.