A course would be overkill. Look for a cheat sheet, then use it to do some actual debugging. You'll find yourself looking up specific things and soon enough you will have explored everything. I will say, if you're on windows, I'd strongly suggest using the rad debugger (shameless self plug) by epic games / rad tools. It's on GitHub. More on reddit.com

I owe beej about 80% of my sockets programming knowledge. Thanks beej.

More on reddit.com

I find this reference card sooooo helpful and it even taught me a few features I didn't know. https://users.ece.utexas.edu/~adnan/gdb-refcard.pdf Keep it handy :) More on reddit.com

Thorough article, and better than I expected! IMHO, the examples ought to use debug level 3, as in -g3 — or if you really insist, -ggdb3. (These days the gdb part is archaic, from a time before DWARF took off.) It includes extras like macro values — really handy at times. Consider: #include int main(void) { return EXIT_SUCCESS; } With -ggdb/-g: $ cc -ggdb main.c $ gdb a.out (gdb) start Temporary breakpoint 1, main () at main.c:5 5 return EXIT_SUCCESS; (gdb) p EXIT_SUCCESS No symbol "EXIT_SUCCESS" in current context. With -g3: $ cc -g3 main.c $ gdb a.out (gdb) start Temporary breakpoint 1, main () at main.c:5 5 return EXIT_SUCCESS; (gdb) p EXIT_SUCCESS $1 = 0 If you're going to ship debug information, such as a debug symbol package in a distribution, then perhaps -g makes sense because -g3 can be quite large. Otherwise either you want no debug information (releases) or as much as possible. (Note: symbol information is distinct from debug information.) Most build systems get this trade-off wrong by default. A debugging article that doesn't at least mention sanitizers is incomplete as well. They're a game changer! Address Sanitizer does produce that backtrace on crash: $ gcc -g3 -fsanitize=address -o crash crash.c $ ./crash AddressSanitizer:DEADLYSIGNAL ================================================================= ==47141==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 ... ... #2 0x557be2160174 in do_something crash.c:6 #3 0x557be2160185 in main crash.c:11 ... And Undefined Behavior Sanitizer even explains it: $ gcc -g3 -fsanitize=undefined -o crash crash.c $ ./crash crash.c:6:5: runtime error: null pointer passed as argument 1, which is declared to never be null Either can be configured to trap in GDB just like a failed assertion: export ASAN_OPTIONS=abort_on_error=1:halt_on_error=1 export UBSAN_OPTIONS=abort_on_error=1:halt_on_error=1 Which really complements GDB. But don’t despair. There is a faster way to break out of the loop. Just set a breakpoint to line 9 which is the first line after the loop: (gdb) break step.c:9 The article also mentions tbreak, but there are two even better tools: until (u) and advance (adv). The first, given no argument, will break at a higher line number, useful for getting past loops. The second is more general, combining tbreak with continue, continuing execution until reaching the given location, which need not even be local. There is nothing wrong with printf debugging. Eh… that's something people do when they don't know any better or their tools are terrible (i.e. no/poor debugger). Perhaps it's more advanced, but dprintf is worth a mention. Want a "trace" of some value over time? Throw a dprintf on it. Log of all malloc allocations (SysV ABI)? (gdb) dprintf malloc,"malloc(%zu)\n",$rdi It could be better. It's not simple to, say, capture the output in a file, and it doesn't compose with most other GDB features, notably artificial arrays . Speaking of which, the article didn't mention those! I use them all the time. $ gdb a.out (gdb) set args --foo bar baz (gdb) start Temporary breakpoint 1, main (argc=4, argv=) at main.c:3 3 return 0; (gdb) p *argv@argc $2 = {"/tmp/a.out", "--foo", "bar", "baz"} I use commands as a workaround when dprintf isn't enough. Example: #include typedef struct { char *data; int len; } str; static str example(str s) { return s; } int main(int argc, char **argv) { for (int i = 0; i < argc; i++) { str s = {argv[i], strlen(argv[i])}; example(s); } } Then: (gdb) b example Breakpoint 1 at 0x114e: file main.c, line 10. (gdb) commands Type commands for breakpoint(s) 1, one per line. End with a line saying just "end". >silent >p *s.data@s.len >c >end (gdb) r --foo bar baz Starting program: /tmp/a.out --foo bar baz $1 = "/tmp/a.out" $2 = "--foo" $3 = "bar" $4 = "baz" [Inferior 1 (process 47950) exited normally] A little tedious to set up, but sometimes called for. More on reddit.com