Monday, August 02, 2010

C++ debugging tools: Gdb, CppCheck, Valgrind

One of the most important parts of programming is the debugging phase, and for development, the testing phase. Some of the tools that can be used under OSX are the standard linux tools - but ofcourse, there are always a few tweeks.

CppCheck is a static analysis tool, it can find formatting issues, unused variables or sub-optimally used variables, pointer/memory issues, etc.

The install procedure for CppCheck is:
git clone git://
sudo make install

sudo easy_install Pygments-1.3.1-py2.6.egg

cd htmlreport
sudo ./ install
(The python aspect you only need for a nice html report)

Note, I had to check out v 1.44 for it to work with OSX, so after the git checkout command add the following:
git checkout 1.44
git checkout -b 144

Here is an example shell script to run cpp-check (thanks John):
cppcheck --enable=all --xml --verbose -f -I math -I boost/boost -I src/framework src 2> err.xml
cppcheck-htmlreport --file err.xml --report-dir="CodeAnalysisReport" --title="My Project"
Just alter it to match your own include directories and source.

If you need to do any runtime debugging, GDB is the standard tool. It can be quite complex, but here is its basic usage:
  • gdb (program name) [this will start GDB with your program loaded]
  • set args (arguments) [this will set the command line parameters to your program]
  • break (function/bp) [eg: break lib/preprocessor.cpp:610]
  • r [run]
  • bt [trace]
  • q [quit]
Not as good as the MS debug tools, but its still far better than not having a debugger at all! Finally, Valgrind is a tool for memory-checking. It normally works out of the box, but I had to make some changes for OSX. Luckily Greg Parker already wrote a patch, and Cristian Draghici wrote up a blog post on compiling and installing valgrind on OSX.


Daniel Marjamäki said...

Interesting post! :-)

So latest Cppcheck head doesn't work on MAC? I wonder what is wrong. If you find out any problem let us know.

gdb has many more tricks.

One pretty cool trick is to debug in reverse:
(gdb) break some_error
(gdb) record
(gdb) continue
-- reached some_error
(gdb) rn

The rn command stands for "reverse next" and it will step your program backwards.

One trick I often use in gdb is the ability to call functions. I often use it to call functions that print debugging information.
(gdb) call printInfo(data)

Visual Studio has a data inspector that does this but for complex datastructures it's really nice to be able to write a custom 'printInfo' that outputs better information.

cameron royal said...

valgrind is the one tool I have yet to find a good windows equivalent for - nothing compares to it for tracking memory leaks. Not quite sure how it works too which is part of the fun, computer science voodoo.

Adrian said...

Thanks for the tips danmar! I'll probably give cppcheck head another try next week and see if I can debug it.

I vaugely recall some memory checker from a company with 'fluid' in its name for windows. But MSVC can do memory tracking with some extra macros enabled. (_CrtSetDbgFlag)