LLDB: Stop Time with Breakpoints

Why it exists

When a program crashes or behaves unexpectedly, the final state often doesn't reveal the root cause. You need to know the state of variables and the call stack at the exact moment things went wrong. While print statements can offer clues, they are static and require recompiling. Breakpoints provide a dynamic, interactive way to pause and inspect a running program.

The mental model

Think of a breakpoint as a pause button for your code's execution, controlled by the LLDB debugger. When the program hits a line with a breakpoint, it freezes. This allows you to step out of the normal flow of time and become an inspector, examining variables, memory, and the execution path up to that point, just like a detective examining a crime scene.

How it works

LLDB, the default debugger in Xcode, instruments your running code. When you set a breakpoint—either by clicking in Xcode's gutter or using a command like breakpoint set --file main.swift --line 42—LLDB tells the process to halt when it reaches that specific instruction. Once paused, you have a command-line interface to the program's state. You can print object descriptions with po, inspect raw variable values with v or frame variable, and control execution with commands like continue (resume), next (step over), and step (step into).

When to use it

Use breakpoints when you have a reproducible bug and a hypothesis about where in the code it might be originating. They are perfect for verifying assumptions about variable values, checking if a certain code path is executed, or understanding the flow of an unfamiliar codebase by pausing at key functions.

When not to use it

Avoid breakpoints for issues that are highly timing-dependent, like race conditions. The act of pausing the program can alter its behavior and cause the bug to disappear (a "Heisenbug"). For performance analysis or tracking widespread events, logging or dedicated profiling tools like Instruments are more appropriate, as they interfere less with the program's natural execution.

One canonical example

To debug a command-line app named myApp, you can launch it with LLDB. First, set a breakpoint at the main function, then run the program. It will pause at the entry point, allowing you to begin inspection.

$ lldb myApp

(lldb) breakpoint set --name main (lldb) run ...process stops at main... (lldb) po someVariableInMain ...prints the description of the variable... (lldb) continue