Debugging Foundations

Module 65 lessons · 1 labAbout 8 hoursModule overview

Your program prints the wrong total. You’ve read the loop, and you think you know which line is responsible, but reading the same line again isn’t giving you any more evidence. We’d like to stop the program while the calculation is happening and look at the values it actually has.

A debugger is a tool that lets us control a program’s execution and examine its state. We can pause it at a chosen point, look at the values it holds, then let it run a little further and check what changed. That gives us access to evidence the program never prints: function arguments, local variables, the calls that brought us here, and the contents of memory and CPU registers.

The Linux, C, memory, and instruction work you’ve already done tells you what those observations mean. Now we can put our explanation next to a running process and find out where they disagree.

Learning objectives

Module outcomes

• Launch a known executable in GDB and control where it stops.
• Follow arguments, local variables, and returns through function calls.
• Connect source, instructions, valid memory, and live register evidence.
• Locate the first incorrect state in a small program.
• Verify a minimal correction with a failing case and regression tests.

Before opening the debugger

Finish Programming Foundations and How Programs Work through Programs Asking Linux for Help. You should be able to rebuild C, trace a loop, explain a pointer’s lifetime, and read a small disassembly. The Code Investigation Lab practiced diagnosis without a debugger; we’re adding a way to observe intermediate state, not replacing that method.

Use the existing Ubuntu x86-64 course VM. The first lesson installs GDB inside that guest and verifies it. All examples are local, single-threaded programs whose source is supplied. They need no network after tool installation and no administrator privileges to debug. Leave unrelated processes alone.

The sequence

1. Stop a Program and Look Inside — identify the build, pause in a function, and inspect an argument.
2. Follow Values Through Function Calls — choose how to step and read state in the correct frame.
3. Connect Source to Live Machine State — connect the familiar instruction view to an actual execution.
4. Find Where a Value Goes Wrong — compare predicted changes with observed ones.
5. Explain the Failure and Verify the Fix — distinguish a failed condition from its cause and test a correction.
6. Explain the Wrong Report — choose your own observations and defend a diagnosis.

Allow about eight hours including the lab, with more time if compilation or function calls still need practice. The Program Investigation Capstone follows this module and brings debugging together with the other views you’ve learned.

What counts as a useful stop?

A debugger can show you an impressive quantity of numbers. We want the few that answer your question. Before each stop, predict a value or a path. Afterward, say whether the observation supports that prediction, contradicts it, or leaves the question open.

The next vulnerability research course will use this fluency for security-focused investigation. Here, success means explaining an ordinary program error and testing a correction. A surprising number in a debugger is still just a surprising number until you’ve established what produced it.

Begin with Stop a Program and Look Inside.