GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

GDB can make your program stop on specified conditions, examine what has happened, when your program has stopped, and even change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another.

Please refer to the official GDB documentation for all the information on how to use this tool.

A basic use case: inspecting a core dump

If your program fails with a Segmentation fault, Memory fault or similar, it may be useful to generate a core file and inspect it later to get a better insight on where and why it fails. In order to generate and be able to use a core file, you should make sure that:

• you have compiled your program with the "-g" option so the executable contains all the necessary debug information

• Core dumps are enabled at runtime. By default, they will be disabled so no core dump will be generated on failure. To change that, make sure you have run the following in your script or debugging session:

  ulimit -c unlimited

  
  

When your program fails, it should generate a core file in the current working directory of the job or session, which you will be able to inspect with:

gdb <your executable> <core file name>

Once inside, you can run the backtrace command in the gdb prompt to get the call stack information.