DDT debugger on Aurora
A basic description on how to start a debugging session with DDT, part of ARM Forge, on the Aurora systems. Job will be submitted through the Slurm batch system to the back-end nodes.
About this document
This document gives basic instruction on how to start a debugging session using the DDT debugger on the Aurora system at LUNARC. This document is based on DDT version 6.0.2 currently installed on Aurora. There is currently a centralised SNIC license hosted by NSC. The licenses are shared between the users of all the SNIC systems. So please be considerate to other users fellow regarding for how many licenses your use (time and number of cores).
DDT is a powerful debugger for serial and parallel programs. The tool is developed and maintained by ARM. It is part of the ARM's Forge suite. A number of parallel programming models are supported. This includes MPI, OpenMP and a number of GPU languages. This document is not a DDT userguide, we refer our users to the documentation available from the ARM website, in particular their user guide.
Getting started with DDT on Aurora
Connect to Aurora via the LUNARC HPC desktop
To use DDT you need to be able to access its graphical user interface (GUI).
The recommended way to connect to the system is via the LUNARC HPC desktop.
Starting the DDT GUI on Aurora
LUNARC currently recommends using reverse connect to start DDT. Load the relevant module. On Aurora the module name is arm_forge. Load it:
module load arm_forge
You can now start the GUI by typing
at the command prompt. This will bring up the following GUI window
In the bottom left hand corner you get confirmation whether you managed to reach the license server at NSC.
Preparing and running your executable
We have seen issues when sources and/or executables are placed on the /lunarc file system (nobackup space). Copying sources and executables into your home space typically solves the issues.
You need to prepare your executable for debugging. Please recompile and relink everything with debugging support and without optimisation. To do so, for most compilers you need to add the flags
Once your created an executable with debugging support, run it using either a batch script or an interactive session.
Make sure the
arm_forge module is loaded by your script or manually inside your session, before starting the executable. This is in addition to the modules normally required to execute your code.
To start your program, prefix the execution statement with
ddt --connect. For example an MPI code compiled against an OpenMPI-library should be started as follows
ddt --connect mpirun program_g
with the executable being named program_g. In case of the Intel MPI-library the code gets started using srun
ddt --connect srun program_g
Once your job starts running, you get a request to allow your job connecting to the DDT GUI
Accept this to get to the next window.
In this window you can select the features of ddt which you require. We would like to point out the Memory Debugging, which can be extremely useful when trying to resolve segmentation faults and memory leaks. Please consult Allinea's user guide for more details and side effects (e.g. increased memory consumption) of using this feature.
Hit the run button to start the debugger window
In the GUI you can run your code (parallel or serial), set breakpoints, examine values of variables and data structures.
During a debugging job it is often required to restart the program execution from the beginning. We recommend not to choose the Restart Session option from the File pull down menu to restart the programs execution from the beginning:
In particular when using DDT from a batch script, using this option will keep your script active and you do not need to re-queue.
If you want to start over for e.g. changing the level of memory debugging, we recommend using the End Session option from the File pull down menue:
Using this option will terminate the ddt execution, but keep the GUI alive, which is often advantageous when using ssh -X to connect to the cluster. If working from a batch script, its execution will then continue to the next line(s) which typically leads to the script finishing and requires you to re-queue. An interactive session will keep running, if the time limit has not been reached.