Besides things that have already been posted i also use:

• a .gdbinit file for STL containers
• signal SIGNAL noprint nostop for some custom signals that are of no real interest when debugging
• C-Casts to dereference pointers
• catchpoints (catch throw, catch catch)
• condition for conditional break- and watchpoints
• rarely gdbserver for remote debugging
• gdb program coredump, for those embarassing segfaults ;)

PS: One reason i personally love gdb btw. is that it supports tab-completion for nearly everything (gdb commands, symbols in the symbol table, functions, memberfunctions etc.). This is a fairly good productivity boost in my opinion.

Summarizing the comments (before anyone else does :).

Your executable file is missing the symbolic information that gdb needs to display the relevant source code. You need to add the -g option to the compile command and produce a new executable. Then re-run your failing test to produce a new core file. gdb with this executable and core will be able to show you the stack of function calls using backtrace.

In a makefile, the easiest way to do this is to add (to) the CFLAGS variable which is used with the implicit .o.c rule.

CFLAGS= -g -Wall -Wextra

You can also add this directly to the command-line (assuming a decent shell :). This sets the value as an environment variable during the execution of the make command (and sub-commands).

$ CFLAGS='-g -Wall -Wextra' make

I'd actually recommend you add this to your bash .profile, so you always get the most information from the compiler.

CFLAGS='-Wall -Wextra'

Then, when you need it, put this in the makefile to make a debuggable executable:

CFLAGS+= -g