A typical software application is built from a code base containing thousands of lines, and a complex application easily reaches into the millions as its developers add ever more functionality. However, each line of code in a project is a place where somebody could have made a mistake, and even a single coding mistake among millions of lines can bring everything crashing down if it falls in a critical area. Many programmers become reliant on simple visual inspection and peer review to find lines of code that might contain mistakes, an approach that proves utterly unworkable when scaling to a code base of significant size, not to mention the fact that imperfect human eyes miss things all the time when examining code bases of any size. It's inevitable, then, that we'll need to use tools of some sort to analyze our code base. Ideally, these tools would be rolled into an automated build that processes all code after each change is committed, thereby giving us a system of continuous integration. On a team with multiple developers, such a system is invaluable; if any individual commits a change found to cause errors, we can easily revert the code its previous and known good state.
Today, we'll take a look at valgrind, a tool that comes in very handy as part of an automated build for C/C++ code. In applications built from these languages, the memory leak is one of the most common types of bugs as well as one of the most pernicious, often causing the user's system to slow to a crawl before an inexorable process crash hits. With valgrind's help we can flush out such leaks, along with several other types of issues related to memory management. Furthermore, by incorporating valgrind into a project as a build step, we can detect critical bugs as soon as they are coded, hopefully preventing their propagation to production sources and keeping them out of the hands of users.
This article refers to sample source files, which are available for cloning in the valgrind-testapp project on GitHub.