That's a great article! As the article says, "Valgrind should be your tool of <i>first</i> resort". Running clean under Valgrind (as well as without warnings under -Wall -Wextra) is a good requirement for quality code. And it's worth mentioning that although C++ is the example the author chose, Valgrind works on any binary regardless of the language it's written in.<p>Leaked memory at close might be OK, but "uninitialized value" or "illegal access" almost never is. And if for some reason you think it is OK in your particular case, don't just ignore the warnings. Either change your code, or use a suppression file (<a href="http://valgrind.org/docs/manual/mc-manual.html#mc-manual.suppfiles" rel="nofollow">http://valgrind.org/docs/manual/mc-manual.html#mc-manual.sup...</a>), or the macros in valgrind.h (<a href="https://raw.githubusercontent.com/svn2github/valgrind/master/include/valgrind.h" rel="nofollow">https://raw.githubusercontent.com/svn2github/valgrind/master...</a>) to so that others don't waste time on it. And realize that more often than not Valgrind is right and you are wrong. :)<p>The small changes I might suggest to the article are to add "-g" to the command line flags you always use (it makes debugging a lot easier, and while it makes the executable larger, it almost never makes the code slower); to emphasize more strongly that Valgrind is not a static analyzer and will only catch errors in your code if the execution actually triggers them; to say that "-pedantic" is a good choice if you want code portable to all standards compliant compilers but may not be a good choice otherwise; and to suggest that if you are on Linux, 'perf' is a better first-line profiler than 'callgrind'.
valgrind proper is actually a much more general binary instrumentation/execution engine that supports a number of different useful tools; most of what the article is <i>actually</i> describing is memcheck, the tool it runs by default when you don't specify another. While the article does mention helgrind and callgrind, it glosses over the true generality of valgrind in offering the "plugin" structure via which those are implemented.
Should there be some mention of the need for caution with the results of Valgrind?<p><a href="https://www.schneier.com/blog/archives/2008/05/random_number_b.html" rel="nofollow">https://www.schneier.com/blog/archives/2008/05/random_number...</a>
I love valgrind and it saved my ass countless time when tracking memory leaks or overflows. The main issue I've always had with it is filtering the output easily. When you use external libraries (portaudio or Qt for example but also proprietary libraries I had to use at work) a lot of the debug messages pollute what is really <i>yours</i> and your leak is then a needle in a haystack.
I tried to run a very small (2k CLOC) C program under Valgrind, unfortunately I was using OpenSSL before the layman knew what a ghetto that could be. I tried a myriad of things to suppress all the insane illegal pointer dereferencing and processor instruction probing by OpenSSL to no avail, and couldn't find bugs in my own code, owing to all of this noise!<p>I learned too late (blame my feeling overwhelmed whilst playing outside my preferred toolbox) that there's a solution, quoting the OpenSSL docs:<p>> When OpenSSL's PRNG routines are called to generate random numbers the supplied buffer contents are mixed into the entropy pool: so it technically does not matter whether the buffer is initialized at this point or not. Valgrind (and other test tools) will complain about this. When using Valgrind, make sure the OpenSSL library has been compiled with the PURIFY macro defined (-DPURIFY) to get rid of these warnings. (<a href="http://www.openssl.org/support/faq.html#PROG14" rel="nofollow">http://www.openssl.org/support/faq.html#PROG14</a>)<p>Unfortunately that didn't help me either, as I couldn't get -DPURIFY to work, the compile phase too forever, and I'm not skilled with cross compiling, and my target platform was a RaspberryPi. Apparently I hadn't set myself up for success.<p>I hope someone else can appreciate Valgrind and avoid stumbling into the issues that I faced, and perhaps learn something about OpenSSL compile flags along the way!
Unfortunately both ASAN and Valgrind are broken on FreeBSD. ASAN has the decency to tell you it doesn't support FreeBSD, but while Valgrind doesn't even build in FreeBSD and doesn't list FreeBSD as a supported platform, the FreeBSD port is available but completely borked when testing clang-compiled software (which is everything on FreeBSD these days).<p>I have to compile my FreeBSD-specific code on Linux to find memory leaks, while praying to God the leak isn't in one of the ifdef'd sections.
I wrote my first sizable professional C program a few years ago. There were issues with some slow memory leaks in my code. I'd only vaguely heard of valgrind before, but I decided to give it a try. A day of debugging with it caught issues that would have taken months to shake out otherwise, if at all. (It also helped me track down the memory leaks.)
Nice article, although I'm not convinced by the first example (as is it now, and in first position): detecting uninitialized variables is a job for compilers: `gcc -Wuninitialized -Wmaybe-uninitialized`. That works well within a single scope, as it's the case in the example. In more complex situations, like an uninitialized field inside a linked-list structure, valgrind will be very useful indeed! By the way, `gcc -O0` sets my uninitialized variables to 0 without a warning, and valgrind is happy as well ...
Valgrind is amazing but i can't ever figure out how they name these things. It seems like the only rule is computer jargon followed by the word grind.<p><pre><code> valgrind - a multipurpose tool
kcachegrind - a gui for callgrind
helgrind - data race analyzer
</code></pre>
Am I the only one that thought "what the fuck" when they heard kcachegrind for the first time?<p>EDIT: just read this, explained everything: <a href="http://valgrind.org/info/tools.html" rel="nofollow">http://valgrind.org/info/tools.html</a>
Back in the days I still did windows software, VS6 reigned supreme, and BoundChecker and Purify did more or less what Valgrind did (valgrind was already very helpful; purify was available on unixes and windows, and was more capable than valgrind at the time)<p>What's the situation in Windows land these days with respect to these tools?
Valgrind is wonderful for catching bugs in my C code. It's a shame you even have to use a tool like this, but such are the realities of C programming.
vgdb (the GDB interface binary) plus --tools=massif is like magic for finding resource hogs: hit a break point, dump heap profile, step, run another dump, compare.<p>If you often find yourself staring at the massive massif "massif" (triple pun FTW) and wondering why things are going up AND down, you need vgdb in your life.
Not a fan. These tools over-report to the point of uselessness. I get 100 pages of things allocated once and released on exit - which are NOT leaks and not useful to fix. Except to satisfy an OCD impulse.<p>I imagine there's a way to get only a report of repeated allocations, but somehow I never can find it. I have to wonder, why doesn't the tool produce that report by default? Its what I always want.<p>Anyway I can count on 1 hand the times this class of tool has found anything of value. They are not worth the effort 99% of the time.