Rust/Windows: continue_execution re-stops at the same breakpoint (never advances without a step_over)

[debugmcpdev]

Context

Found while live-verifying PR #254 on Windows (CodeLLDB 1.11.8, MSVC-built example with LLDB_USE_NATIVE_PDB_READER=1).

Problem

With a breakpoint at examples/rust/hello_world/src/main.rs:26, once the session is paused at that breakpoint, continue_execution succeeds (success: true) but the session immediately re-stops at the same breakpoint (same line, same threadId, stopReason: "breakpoint", fresh lastStop timestamp). Repeats indefinitely — the program never advances past the line by continue alone.

Reproduced twice in one session:

• 19:54:26 paused at main.rs:26 (breakpoint)
• continue_execution → 19:55:19 paused again at main.rs:26 (breakpoint)

Workaround

step_over once (moves to line 27), then continue_execution runs to completion normally.

Notes

• Likely LLDB-on-Windows failing to step over the re-armed breakpoint trap before resuming (classic breakpoint-re-hit behavior), possibly specific to the native PDB reader path.
• Not covered by existing e2e: tests/e2e/mcp-server-smoke-rust.test.ts inspects locals at the breakpoint but never continues past a user breakpoint to completion; the async test only steps.
• The new Rust get_output e2e assertion in PR feat: forward adapter-process stdio as debuggee output events — Ruby all platforms, Rust on Windows (#222, #223) #254 was deliberately written to not require continuing past a breakpoint because of this quirk.
• Worth checking whether the first "paused, reason: breakpoint" reported by start_debugging is actually the Windows initial system stop being mislabeled — in the same session, the real user breakpoint was only reached after one continue (see skill note "Windows initial stop" in skills/debugging/references/rust.md:55).

[debugmcpdev]

Scoping + experiment results (2026-08-04)

Our continue path is clean

continue_execution sends exactly one DAP continue (session-manager-operations.ts continue()); setBreakpoints/configurationDone are launch-time only; js-debug's mirroring/barrier machinery is inert for Rust; handleAutoContinue can only fire on a literal reason: 'entry' first stop. Nothing re-sends or re-arms breakpoints on continue.

The re-stop comes off the wire from CodeLLDB

A live Windows trace (logs/debug-mcp-server-31760.log, 2026-08-04, CodeLLDB 1.11.8, MSVC binary) shows the first stop carrying hitBreakpointIds: [1] — a genuine user-breakpoint hit, not a mislabeled loader stop — and then CodeLLDB's stop reasons inverting: three step operations reported as reason: 'breakpoint' and the continue reported as reason: 'step' ~4ms after the request. Our layers pass these through verbatim.

Experiment 1 — native PDB reader toggle (Windows): hypothesis falsified

With LLDB_USE_NATIVE_PDB_READER=0 (DIA reader) the behavior is byte-for-byte identical: pause at the breakpoint line, continue re-stops at the same line (twice confirmed), step_over + continue runs to completion. Symbol resolution stayed correct under both readers. The PDB-reader setting is not the cause.

Experiment 2 — Linux repro attempt: does not reproduce

Same scenario (breakpoint examples/rust/hello_world/src/main.rs:26) against a natively-compiled Linux binary with the vendored codelldb/linux-x64 (DWARF): after the breakpoint hit, continue ran straight to completion (exit 0, all post-line-26 stdout captured). Note the shipped Docker image structurally excludes the rust adapter (DEBUG_MCP_DISABLE_LANGUAGES=rust,go,dotnet hardcoded in the Dockerfile), so this ran in a custom container using MCP_RUST_ALLOW_PREBUILT=true.

Platform matrix

Platform	Symbols	Re-stop on continue?
Windows, native PDB reader (default)	PDB/MSVC	Yes, repeatable
Windows, DIA reader (LLDB_USE_NATIVE_PDB_READER=0)	PDB/MSVC	Yes, identical
Linux	DWARF	No

Conclusions

• Windows-specific CodeLLDB/LLDB breakpoint re-hit behavior on MSVC binaries (LLDB's step-off-breakpoint plan reporting a stop instead of resuming), independent of the PDB reader. A fix belongs upstream; a step-then-continue heuristic on our side can't distinguish the bug from a legitimate same-line loop re-hit, so we're not shipping one.
• Workaround (documented in the debugging skill): on Rust/Windows, step_over once, then continue_execution proceeds normally.
• Two residual notes for our side: (1) start_debugging's stop-reason fallback (session-manager-operations.ts ~:692-699) hardcodes 'breakpoint' when the session is PAUSED with lastStop unset — it didn't fire in these traces but is worth hardening someday; (2) no Rust test asserts that continue-from-breakpoint actually advances — that's the reproducer a future fix should add (currently it would fail on Windows).

[debugmcpdev]

Platform matrix update (2026-08-06)

The new e2e reproducer's win32 probe (PR #274) reproduced the continue-re-stop on a GNU/DWARF build (cargo +stable-gnu build --target x86_64-pc-windows-gnu, CodeLLDB 1.11.8):

Platform	Symbols	Re-stop on continue?
Windows, native PDB reader (default)	PDB/MSVC	Yes
Windows, DIA reader	PDB/MSVC	Yes
Windows, GNU toolchain	DWARF	Yes (new)
Linux	DWARF	No

So the bug is Windows-specific, not symbol-format-specific — the earlier MSVC/PDB framing was too narrow. One observation from a related trace that may be the actual mechanism: the line-26 breakpoint resolves to 3 locations on Windows builds (Resolved locations: 3), and step/continue interactions were seen re-hitting the same breakpoint id on another location of the same line. LLDB's step-off-breakpoint plan may only step past the current location before resuming, immediately trapping on the next location bound to the same line — which would also explain why single-location Linux line tables don't reproduce.

Residual scope from the scoping comment is now shipped in PR #274:

• e2e reproducer (strict single-continue-to-completion on non-Windows; probe + workaround on Windows with breadcrumbs in both directions)
• start_debugging PAUSED-without-lastStop fallback hardened ('unknown' instead of a fabricated 'breakpoint')
• rust.md platform matrix corrected

Leaving this open as the upstream tracking issue — the strict reproducer on ubuntu CI is the tripwire that flips when upstream fixes it.

[debugmcpdev]

Resolution: not a bug — multi-location macro breakpoints

Validating the Rust trio on Ubuntu (x86_64, CodeLLDB 1.11.8, rustc 1.91.1) reproduced this on Linux, which contradicted the "Windows-specific / Linux remains clean" conclusion and prompted a full root-cause pass. The behavior is expected LLDB semantics, not a defect in CodeLLDB, in Windows, or in mcp-debugger.

Root cause

The breakpoint line in every repro — examples/rust/hello_world/src/main.rs:26 — is:

let message = format!("Language: {}, Version: {}", name, version);

format! expands to several inlined call sites on that single source line, so LLDB plants a breakpoint location at each one. The setBreakpoints response says so explicitly:

{"id":1,"line":26,"message":"Resolved locations: 3","verified":true}

Each continue_execution advances to the next location on the same line. The stop is therefore a genuine, distinct breakpoint hit — same file:line, same breakpoint id, different program counter — and the line is only left once all its locations are drained.

Evidence

Driven with a raw DAP client against the vendored CodeLLDB, with mcp-debugger entirely out of the loop:

line 26 setBreakpoints -> [{"id":1,"line":26,"message":"Resolved locations: 0","verified":true}]
stop #1:      {"allThreadsStopped":true,"hitBreakpointIds":[1],"reason":"breakpoint","threadId":461918}
continue #1 -> stop reason=breakpoint ids=[1] at hello_world::main line=26 col=19 pc=0x55555556C6FF
continue #2 -> stop reason=breakpoint ids=[1] at hello_world::main line=26 col=19 pc=0x55555556C73A
continue #3 -> TERMINATED

Note the PCs differ on every stop. The counter-case confirms it:

breakpoint line	source	resolved locations	continues to completion
26	let message = format!(...)	3	3
13	let name = "Rust";	1	1
42	let sum = a + b;	1	1

Setting the breakpoint after launch (fully resolved, Resolved locations: 3) behaves the same, so it isn't a pending-breakpoint artifact. The #236 post-stop setBreakpoints re-sync was also ruled out by disabling it — no change.

Corrections to the record

• Not Windows-specific. Linux x86_64/GNU reproduces identically. The original Windows observations were this same phenomenon.
• Not symbol-format-specific. Nothing to do with MSVC/PDB or the native PDB reader.
• "Linux remains clean" (from fix(#255): continue-from-breakpoint reproducer + honest stop-reason fallback #274) was an artifact of coverage, not behavior — nothing in the suite had ever continued past a user breakpoint on Linux.
• step_over "works" for the mundane reason that stepping traverses the whole line, including the remaining locations.
• The scoping note that a same-line re-stop is indistinguishable from a legitimate loop re-hit is correct by line — but by PC they are distinguishable, and in this case every stop was legitimate anyway.

Follow-up

#277 replaces the strict reproducer (which fails on main for the reason above) with two tests: a single-location line that must complete in exactly one continue, and a macro line that must drain its locations and then complete. It also rewrites the skills/debugging/references/rust.md guidance, which was directing agents to apply a Windows workaround for cross-platform expected behavior.

Closing as working-as-intended.