Valgrind --- its great!

Hi all,

I've just starting writing C++ again on Linux after a long break. Having gotten comfortably used to the way in which PHP leads you by the hand through everything; going back to C++ was something of a shock!

Anyway, I got pissed off with gdb and it's really useless debugging information and so I found this: http://valgrind.org/

It is the best debugging tool that I have ever found for Linux! I haven't used the visual front-end (Valkyrie) yet, but the Valgrind tool itself is great! It effectively provides a complete VM for your C++ to run on and keeps tabs on all your memory allocations and will warn you, for example, if you are overruning the end of an array, even if the code does not crash. I think it even handles multi-threaded stuff (for example it will, I think, tell you exactly where, why and how a race condition is occuring).

I hope that is useful to someone! Its speeded up my development time immeasurably - no more trying to figure out exactly where that infuriating segmentation violation is occurring ... :thumbsup:

Additional: Having just upgraded to Debian 4.0 (Etch), I've discovered that it is available as a precompiled package ... apt-get install valgrind is all that's required :thumbsup:

valgrind is a great tool, combined with gdb. I also use electric fence, as it's a lot faster and it tends to pick up the same stuff as valgrind without giving me as much spurious junk about builtins that there's no helping.

Don't forget to turn on debugging symbols (-g) and turn off optimizations when compiling for any debugger. The flags I usually use for quality control are

-Wall -Wextra -Wshadow -pedantic -g3 -O0 -lefence


-O0 implies -fno-inline, which makes the call stack explicit to avoid a bit of potential confusion looking at traces.

edit: gprof is also pretty great for profiling, just compile with -pg (and without -lefence), run the executable to generate statistics and use gprof <executable name> to get the breakdown. Unfortunately for C++ you almost have to use a post-processor because you will find yourself looking at pages and pages of template crap. Something like kprof truncates that stuff and organizes everything usefully.

Also in the way of C[++] dev tools there's mudflap for hunting down overflow violations, but I haven't really bothered with it because the documentation is poor and I can't figure out how to suppress the many pages of spurious errors having to do with things like <vector> internals it reports for even simple programs.

I hadn't heard of electic fence, sounds better without the builtin stuff, although I think valgrind's good for me and I *think* you can turn off builtin stack trace with one of the options ... haven't rummaged through the help for it yet though!

Another of my favorite compiler flags for cross-platform stuff has got be -ansi :)

Incidentally, can you force electric fence ouput as XML? I really like that feature of valgrind.

Nah, no XML.. electric fence is very low frills. Like the name implies it's a memory guard, and the extent of its reporting is dumping core when something dodgy you do trespasses on the bounds it sets around allocated memory. It's really not a replacement for valgrind but it's fast enough to stick in any old compilation, whereas I hit valgrind usually only at major development waypoints since it's sooo slow :/

My only problem with valgrind is that it tells me about problems with the libraries I am using, which makes it hard to find which problems are in my code. I will have to try that electric fence thing.

For some reason I never use debuggers. I seem to always be able to just see the error and where it is happening and then stare at the code until it gets fixed , even on large projects :) Stack traces are very useful things.