In the last week’s section we discussed GDB and Valgrind for debugging serial code. And you already got some hands-on experience with those tools. Over time CPU architecture got more sophisticated, and in order to exploit that hardware we just have to turn to parallel programming, either using multiple threads on a single CPU or multiple processes distributed over many computer nodes, for instance using MPI. However, parallel programming is hard, and it actually opens its very own can of worms, unintented. Data shared between threads or processes, data access and execution have to be syncronised. On a more fundamental level, say bye-bye to the determinism.

You get “heisenbugs”: now you see the bug, and now you don’t. And that depends on the execution order. So, all this serves as even more motivation to use professional tools when debugging parallel code. DDT, which is a part of ARM Forge suit of parallel development tools, is such a debugger. It has a really nice graphical user interface and many features that make debugging parallel code a lot easier. To verify some MPI constructs, or figure out some problems with MPI communication, ITAC (Intel Trace Analyser and Collector tool) is quite valuable. And speaking of valuable, DDT and ITAC are actually commercial products, and the licenses are really, really expensive.

So, we’ll also revisit our good old friend GDB and see what it can do for us in a parallel context. So, in this section you’ll see how to use DDT, ITAC and GDB to find bugs in parallel code effectively and efficiently.