Tip 9: gdb

The GNU Debugger (gdb) is extremely useful as a quick way to find problems in codes. I also like it because it is available on MANY platforms. If it is not on your current platform, it is probably easily available as a pre-built package. Here is a quick start guide to the most useful features. More is available in various tutorials and the man page. You can abbreviate almost any gdb command by typing just enough characters to provide a unique match. Tab completion also works.

gdb can be run in three ways: 1) gdb program (or gdb --args program -my -program -argument) will load your program and give a gdb prompt. 2) gdb program core will run your program using the state saved in a core dump. 3) gdb program pid will attach gdb to an already running program. (There are various ways to attach gdb over a network for embedded processors too...)

Once gdb is running, you have a prompt: (gdb) at which you can tell it to run: (gdb) run

At any time, you can press Ctrl-C to interrupt and return to the debug prompt. Once there, you can single step into functions ("step" or just "s") or go to the next instruction ("next" or "n"). If you want to keep running, you can type "cont" or "c".

Also at the prompt, you may want to see where you are at in the program. To see the current code, you can type "list" or to see the current call stack you can type "backtrace" (or "bt").

If your program experiences a signal (segfault, bus error, fork, etc), it will return to the prompt. At this point, you want to investigate why the signal happened. The call stack is useful for this: