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
• compute-sanitizer is a command-line functional correctness checking suite

Do you find this page useful?

Yes

Thank you for your feedback!

No

Thank you! Your feedback is appreciated.

Please let us know how we could improve this page by contacting us or by creating an issue in GitHub. You can also edit this page yourself and contribute your improvements by creating a pull request.