Memory Leak Detection in C + +

Original link: http://www.linuxjournal.com/article/6556?page=0,0

An earlier article ["Memory Leak Detection in Embedded Systems", LJ, September 2002, available atwww.linuxjournal . com/article/6059] discussed the detection of memory leaks when using C as the programming language. This article discusses the problem of detecting memory leaks in C + + programs. The tools discussed here detect application program errors, not kernel memory leaks. All of these tools has been used with the MontaVista Linux Professional Edition 2.1 and 3.0 products, and one of the them, DM Alloc, ships with MontaVista Linux.

When developing application programs for embedded systems, designers and programmers must take great care with using Sy Stem memory resources. Unlike workstations, embedded systems has a finite memory source. Typically, no swap area are available to idle programs. When the system uses up all of IT resources, nothing is a left-to-do but panic and start-over or kill some programs-make The needed resources. Therefore, it's important to write programs that does not leak memory. Many tools aid programmers in finding these resource leaks. All of the tools discussed this come with their own test programs.

One method of testing, which I has seen used successfully by application developers, involves using a workstation to Deve Lop prototype code and debugging as much as possible on it. Using memory leak tools in the manner is strongly advised. By debugging on a workstation, the application programmer can is assured that the transition to the target processor would Be easier. A major reason for using workstations is they be cheap, and everybody involved has one. Targets, on the other hand, is usually few and in great demand.

Most memory leak detection programs is available as full source. They typically has been built on an x86-based platform. Running them on non-x86 targets requires some porting. This porting effort could is as simple as a recompile, link and run, or it could require changing some assembler code from One platform to another. Some of the tools come with hints and suggestions for use in cross-compiling environments.

Dmalloc

The author of Dmalloc, a tool I covered in detail in the September 2002 article, states this his knowledge of C + + is limit Ed, and thus the C + + detection of memory leaks also is limited. In order to use DMALLOC with C + + and threads, it has been necessary to link the application as static.

Ccmalloc

The Ccmalloc tool is a memory profiler with a simple usage model that supports dynamically linked libraries and not dlopen . It detects memory leaks, multiple de-allocation of the same data, underwrites and overwrites and writes to already De-allo cated data. IT displays allocation and de-allocation statistics. It is applicable to optimized and stripped code and supports C + +. It also provides file and line number information for the whole call chain, not only for the immediate caller of MALLOC/FR EE, and it supports C + +. No recompilation is needed to use ccmalloc; Simply link it with-LCCMALLOC-LDLOrCCMALLOC.O-LDL. Ccmalloc provides efficient representation of call chains, customizable printing of call chains, selective printing of CALs L chains, a compressed log file and a startup file called. Ccmalloc. The major documentation is found in a file named Ccmalloc.cfg. The test files included with the program provide more documentation. NM and GDB is required to get information about symbols and gzip or to compress log files.

Njamd

Njamd is, as the author states, "Not just another malloc debugger". As with most memory allocation debuggers, the standard allocation functions is replaced with new ones that perform Variou s checks as memory is used. Specifically, it looks for the dynamic buffer Over/underflows and detects memory reuse after it is freed. The library built for NJAMD can is ld_preloaded, or it can be linked to the program. It creates a large memory buffer on the first memory allocation, 20MB, and it then carves this to the program needs MEM Ory.

NJAMD can is used alone, with a front end or from within GDB. It has a utility this allows postmortem heap analysis. Another feature allows the application being debugged to skip recompilation; Simply preload the library. NJAMD also is capable of tracing leaks in library functions that wrap malloc and free, GUI widget allocators and C + + new A nd Delete. Often A memory leak is not discovered immediately but lurks, and waiting to strike in the most visible moment. Tracking this down can take a long time. NJAMD has many environment variables the Allow setting varying levels of detection. As with most debugging tools, performance can is a issue with NJAMD, so the tool should is used only during development. Deploying with the tool, enabled can result in slower systems.

Yamd

YAMD (yet another memory debugger) is another package for trapping the boundaries of allocated of memory. It does this by using the paging mechanism of the processor. Read and write out-of-bound conditions is detected. The detection of the error occurs on the instruction that caused it to happen rather than later, when other accesses occur . The traps is logged with the filename and line number with trace-back information. The trace back was useful because most memory allocation was done through a limited number of routines.

The library emulates the malloc and free calls. Doing This catches many indirect malloc calls, such as those made by StrDup. It also catches new and delete actions. If the new and delete operators is overloaded, however, they cannot be caught.

YAMD, like other programs of its type, needs a large amount of virtual memory or swap available to perform its magic. On a embedded system, though, this is typically not available. The earlier suggestion to use this tool on a workstation to do prototype debugging are encouraged here as well. When this debug was done, moving the application to the target can proceed with confidence, if not all, memory le AKS has been found.

YAMD provides a script, RUN-YAMD, that's used to make the program execute easily. It offers several options to try to recover from certain conditions. A log file can be created when the program being checked performs a core dump. A debugger can used to debug yamd-controlled programs. However, problems can arise using a debugger when yamd are preloaded rather than statically linked with the program.

Valgrind

Valgrind is a relatively new Open-source memory debugger for X86-GNU Linux systems. It has more capabilities than earlier tools, but it runs only on x86 hosts. When a program was run under the control of Valgrind, all read and writes to memory, as well as calls to malloc, free, new and delete, is checked. Valgrind can detect uninitialized memory, memory leaks, passing of uninitialized or unaddressable memory, some misuse of P Osix threads and mismatched use of malloc/free and new/delete actions.

Valgrind also can is used with gdb to catch errors and allow the programmer to use GDB at the point of error. When doing this, the programmer can look for the source of the problem and fix it much sooner. In some cases, a patch can made and debugging can continue. Valgrind was designed to work in large as well as small applications, including KDE 3, Mozilla, OpenOffice and others.

One feature of Valgrind is it ability to provide details about cache profiling. It can create a detailed simulation of the CPU ' s l1-d, l1-i and unified L2 cache, and it calculates a cache hits count for Every line of the program being traced. Valgrind have a well-written HOWTO with plenty of examples. Its web site contains a lot of information and is easily traversed. Many different combinations of options is available, and it's left to users to determine their favorite combinations.

Valgrind ' s error display contains the process ID for the program being examined, followed by the description of the error. Addresses is displayed along with line numbers and source filenames. A Complete BackTrace also is displayed. Valgrind reads a startup file, which can contain instructions to suppress certain error-checking messages. This allows-to-focus more on the code at hand rather than pre-existing libraries, that cannot is changed.

Valgrind does its checking by running the application in a simulated processor environment. It forces the dynamic Linker/loader to load the simulator first, then loads the program and its libraries into the Simulat Or. All of the data is collected and the program is running. When the program terminates, all the log data are either displayed or written to log files.

Mpatrol

The Mpatrol library can be linked with your program to trace and track memory allocations. It is written and runs on several different operating system platforms. One distinct advantage of the library is it had been ported to many different target processors, including MIPS, PowerPC, x86 and by some MontaVista customers, to strongarm targets.

Mpatrol is highly configurable; Instead of the using the heap, it can be set to allocate memory from a fixed-size static array. It can be built as a static, shared or Threadsafe library. It also can being one large object file so it can is linked to the application instead of contained in a library. This functionality provides a great deal of flexibility for the end user.

The code it creates contains replacements for different memory allocation and string functions. Hooks is provided so these routines can is called from within GDB. This is allows for debugging of programs, which use Mpatrol.

Library settings and heap usage can be displayed periodically as the program runs. All the statistics gathered during runtime is displayed at program termination. The program had built-in defaults that can being overridden by environment variables. By changing these environment variables in runtime, it becomes unnecessary to rebuild the library. Tuning of the various tests can is done dynamically. All logging are done with files in the current working directory; These can overridden to go to stdout and stderr or to other files.

As the program was running, call stack trace-back information can be gathered and logged. If the program and associated libraries is built with debug information on symbols and line numbers, this information Can is displayed in the log file.

If at some point the programmer wants to simulate a stress test on a smaller memory footprint, Mpatrol can be instructed T o Limit the memory footprint. This allows for testing conditions, the May is readily available in the lab environment. Stress testing in emulating a customer environment or setting up a harsh test harness are made easier with this feature. In addition, the test program can be made to fail a random set of memory allocations to test error-recovery routines. This ability can is useful for exception handling in C + +. Snapshots of the heap can taken to allow the measuring of a and low watermarks of memory use.

insure++

The insure++ product by Parasoft isn't gpled or free software, but it's a good tool for memory leak detection and code C Overage, very similar to Mpatrol. insure++ does do to than Mpatrol in the area of the code coverage and provides tools, that collect and display data. Trial copies of the software can is downloaded and tried for a specified time period on non-linux workstations.

The product installs easily under Linux but was node-locked to the computer in which it is installed. Insure++ comes with a comprehensive set of documentation and several options. The Code coverage tool is separate and comes with the initial package.

Insure++ provides a lot of information about the problems it finds. To use insure++, it's necessary to compile it with the insure++ front end, and which passes it to the normal compiler. This front end instruments the code to use the insure++ library routines. During The compiler phase, illegal typecasts is detected as well as incorrect parameter passing. Obvious memory corruption errors is reported. During runtime, Errors is reported to stderr but can is displayed by a graphical tool. When building a application, either the command line or makefiles can be used, facilitating the building of projects and Large applications.

Execution of the program are simple. insure++ does not require any special commands to execute; The program was run as if it were a normal program. All the debug and Error-trapping code are contained in the insure++ libraries, were linked with the program.

An add-on tool, called Inuse, displays in real time how the program uses memory. It can give an accurate picture of what memory is used, what fragmented it gets and subtle leaks that seem small but could a DD up over time. I had an experience with a client who found that a particular C + + class was leaking a small amount of memory that, on a wo Rkstation, was seen to be quite small. For a embedded system that is expected to is running for months and possibly years, the leak could become quite large. With this tool, the leak is easily traced, found and fixed. Other available tools do not catch this leak.

Code coverage is analyzed by another tool, TCA. As the program was run with insure++ turned in, data can be collected, when analyzed by TCA, paints an accurate pictur E of what code was executed. TCA have a GUI that enhances the display of the code coverage.

Resources

Cal Erickson ([email protected]) currently works for MontaVista Software as a senior Linux Consultan T. Prior to joining MontaVista, he is a senior support engineer at Mentor Graphics Embedded software division. Cal have been in the computing industry for more years, with experience at computer manufacturers and end-user DEVELOPME NT environments.

Memory Leak Detection in C + +