Previously, I wrote about my “golden rule” for reducing the prevalence of memory leaks in your code. One other easy way to prevent memory leaks is to actively seek them out during the development process, instead of waiting around for them to be reported to you as bugs. One good way to do this is to add some time to your schedule so that you can apply the available tools for finding memory leaks and other problems.
Tools for Finding Memory Leaks
Two tools that I have used and found valuable when it comes to finding memory leaks are Valgrind and Coverity.
Valgrind performs many checks on your code, but in my opinion, the most useful ones are related to pointer usage and memory allocation.
Valgrind analyzes your program at runtime and requires significant resources. It may be unsuitable for some embedded applications for that reason, but if you can sufficiently beef up a development system’s memory and storage to run it, or execute your code in another more resource-rich environment, you will find it useful.
The weakness of Valgrind is that since it runs at runtime, you have to be able to exercise many code paths to ensure that you are leak-free. I have found that even if the usual flow of execution for an application is leak-free, it is likely that memory leaks occur in error paths.
Coverity, on the other hand, performs static analysis on your source code, as described in this paper. So, it covers all your error paths. Coverity costs money, but in my opinion, it is well worth it. While it can provide false positives in some cases, the value is in the actual problems it uncovers that are difficult to find with a code review. It is worth examining every item it identifies as being a potential problem. (Incidentally, I recommend this recent article, written by the founders of Coverity, which touches on the organizational difficulties in implementing any automated bug-finding tool.)
Another way to solve the memory leak issue is to replace the standard C++ pointer mechanism with a more advanced replacement. I have used both the Boehm Garbage Collector (GC) for C/C++ and the Boost library smart pointers for this. Since so much of the C library and other libraries you might be using depend on standard pointers, this is obviously not a panacea — there will always be places in your code where you will have to use a standard pointer or go around the constraints of the GC you are using. GC-based approaches may not be appropriate for resource-constrained environments or those where the GC’s requirement that it collects garbage might interfere with timing.
The smart pointers in the Boost library offer reference counting. While, in theory, reference counting requires more cycles of overhead than a GC-based approach, it does offer a predictable use of CPU. Also, the freedom to create C++ objects that are deleted when the last reference to them goes away can allow much simpler designs in some cases, especially when an object is referenced by multiple threads. But be sure to configure the smart pointers to be threadsafe in this case.
Ben Mesander has more than 18 years of experience leading software development teams and implementing software. His strengths include Linux, C, C++, numerical methods, control systems and digital signal processing. His experience includes embedded software, scientific software and enterprise software development environments.