Debugging

Prepare code for debugging

In order to get full debugging information, one needs to usually re-compile the program of interest with the debug flag (-g) enabled. For example, with the GNU compiler:

gcc -g -o example example.c

Memory leaks

A good place to start is to check for memory leaks with Valgrind. It is a versatile tool that is most commonly used to detect memory leaks in the code, but can also be used e.g. to detect errors in threading or to investigate heap and cache usage.

In order to use Valgrind, set up the environment as needed normally by your code and re-compile the code with the debug flag (-g) added.

Running an analysis with Valgrind is simple and can be done either in an interactive session or as a submitted job. In an interactive session the command to use is valgrind ./myprogram, while in a submitted job the command is srun valgrind ./myprogram.

For example, to check for memory leaks in an interactive session:

module load valgrind

valgrind ./example

To run the same analysis as a normal non-interactive job, e.g. when debugging a parallel program, the command to use is srun valgrind ./example.

Debuggers

Fully-fledged debuggers are often needed to really dig into the code execution and to resolve runtime errors. At CSC, several debuggers are available:

  • Arm DDT is a debugger for serial and parallel programs (MPI, OpenMP, CUDA) with both graphical and command-line interfaces
  • GDB is a command-line debugger for compiled programs (C, C++, Fortran, etc.)
  • PDB is an interactive debugger for Python programs
  • CUDA-GDB is a command-line debugger for CUDA programs

Last edited Fri Jul 31 2020