Skip to content

Call Stack

The Call Stack answers one question: how did execution get here?

Ctrl+C opens it. Each row is a frame — a function that is currently in progress — with the innermost one on top. The bottom row is where the thread started.

Selecting a frame

In this panel the cursor and the selection are the same thing: moving with J / K or the arrow keys selects the frame immediately, no Enter needed. Every other panel follows the selection:

  • Variables shows that frame's scopes;
  • Evaluate evaluates expressions in that frame;
  • Watches re-evaluate against it;
  • the source panel shows that frame's line.

Selecting a frame does not move execution. You are looking at the past of the current stop, not rewinding to it.

Reading a stack

Work downwards from the top frame. The first frame whose code you own is usually where the problem is: everything above it is library or runtime code doing what it was asked.

When a stack is mostly frames you do not recognise, that is a sign the failure was triggered from inside a framework — look for the first frame in your project and inspect its variables.

Frames without source

A frame can point at code the debugger cannot show: a standard library compiled without debug info, a dependency whose sources are not on this machine, or code in a container at a path that does not exist locally.

The frame still appears and can still be selected — its variables may be available even when its source is not. If frames you do own show no source, the paths disagree, and that is fixed with path mappings: Troubleshooting → Source not found.

Deep stacks

Recursive programs produce very long stacks. G jumps to the top, Shift+G to the bottom — usually faster than scrolling to find the boundary between your code and the runtime's.