I stumbled upon a tool with high potential when tracing/profiling under linux. I’ll immediately take you to an excerpt from the Valgrind Quickstart:
The Valgrind tool suite provides a number of debugging and profiling tools. The most popular is Memcheck, a memory checking tool which can detect many common memory errors such as:
- Touching memory you shouldn’t (eg. overrunning heap block boundaries, or reading/writing freed memory).
- Using values before they have been initialized.
- Incorrect freeing of memory, such as double-freeing heap blocks.
- Memory leaks.
Memcheck is only one of the tools in the Valgrind suite. Other tools you may find useful are:
- Cachegrind: a profiling tool which produces detailed data on cache (miss) and branch (misprediction) events. Statistics are gathered for the entire program, for each function, and for each line of code, if you need that level of detail.
- Callgrind: a profiling tool that shows cost relationships across function calls, optionally with cache simulation similar to Cachegrind. Information gathered by Callgrind can be viewed either with an included command line tool, or by using the KCachegrind GUI. KCachegrind is not part of the Valgrind suite — it is part of the KDE Desktop Environment.
- Massif: a space profiling tool. It allows you to explore in detail which parts of your program allocate memory.
- Helgrind: a debugging tool for threaded programs. Helgrind looks for various kinds of synchronisation errors in code that uses the POSIX PThreads API.
- In addition, there are a number of “experimental” tools in the codebase. They can be distinguished by the “exp-” prefix on their names. Experimental tools are not subject to the same quality control standards that apply to our production-grade tools (Memcheck, Cachegrind, Callgrind, Massif and Helgrind).
The rest of this guide discusses only the Memcheck tool. For full documentation on the other tools, and for Memcheck, see the Valgrind User Manual.
What follows is the minimum information you need to start detecting memory errors in your program with Memcheck. Note that this guide applies to Valgrind version 3.3.0 and later. Some of the information is not quite right for earlier versions.
Tried it a few times, and it seems up for the job, yet there are some hiccups.
Memcheck is not perfect; it occasionally produces false positives, and there are mechanisms for suppressing these (see Suppressing errors in the Valgrind User Manual). However, it is typically right 99% of the time, so you should be wary of ignoring its error messages. After all, you wouldn’t ignore warning messages produced by a compiler, right? The suppression mechanism is also useful if Memcheck is reporting errors in library code that you cannot change. The default suppression set hides a lot of these, but you may come across more.
Memcheck cannot detect every memory error your program has. For example, it can’t detect out-of-range reads or writes to arrays that are allocated statically or on the stack. But it should detect many errors that could crash your program (eg. cause a segmentation fault).
Try to make your program so clean that Memcheck reports no errors. Once you achieve this state, it is much easier to see when changes to the program cause Memcheck to report new errors. Experience from several years of Memcheck use shows that it is possible to make even huge programs run Memcheck-clean. For example, large parts of KDE 3.5.X, and recent versions of OpenOffice.org (2.3.0) are Memcheck-clean, or very close to it.