Repository navigation
Debugger shows incorrect thread state if "continued" arrives too soon after a "stopped" (or "started"?) #238591
Description
I had a bug raised against Dart where the debugger shows threads as "paused on entry" when they should not be. The DAP traffic looks good:
// Start
[5:17:21 PM] [DAP] [Info] <== {"seq":21,"type":"event","body":{"reason":"started","threadId":3},"event":"thread"}
// Pause
[5:17:21 PM] [DAP] [Info] <== {"seq":43,"type":"event","body":{"allThreadsStopped":false,"reason":"entry","threadId":3},"event":"stopped"}
// Resume
[5:17:21 PM] [DAP] [Info] <== {"seq":78,"type":"event","body":{"allThreadsContinued":false,"threadId":3},"event":"continued"}
Yet the UI shows the thread as paused. I was able to reproduce this in MockDebug. It seems to only occur when the events occur close together (if I add delays, it doesn't seem to happen):
// Start additional threads, pause on entry, continue.
for (var i = 2; i < 5; i++) {
this._threads.push(new Thread(i, `Thread ${i}`));
this.sendEvent(new ThreadEvent('started', i));
this.sendEvent(new OutputEvent(`Thread ${i} started\n`));
this.sendEvent(new StoppedEvent('entry', i));
this.sendEvent(new OutputEvent(`Thread ${i} stopped on entry\n`));
// await this.delay(1); // Uncomment this to fix it
this.sendEvent(new ContinuedEvent(i, false));
this.sendEvent(new OutputEvent(`Thread ${i} continued\n`));
}
Full repro is here:
https://github.com/DanTup/vscode-mock-debug/tree/repro-dart-code-5397 / DanTup/vscode-mock-debug@04f4764
This felt a bit like microsoft/debug-adapter-protocol#513 to me, but that actually turned out to be caused by allThreadsStopped defaulting to true. I don't believe that's the case here because in the real project where this happens (Dart debugger), we set both allThreadsStopped and allThreadsContinued to false (though I haven't set allThreadsContinued in the MockDebug example because it doesn't seem to be available in the constructor... I don't believe that's the issue though as allThreadsContinued seems to default to false and the delay shouldn't fix the issue in that case).
Activity
vasilich6107 commentedon Jun 3, 2025
Rodsevich commentedon Jun 30, 2025
yohanangulo commentedon Jul 20, 2025
vasilich6107 commentedon Jul 20, 2025
ChuckPG commentedon Jul 30, 2025
roblourens commentedon Jul 31, 2025
I think this is because we have not done
fetchThreadsyet when the 'continue' event comes in. Connor Peet (@connor4312) this might be from #197397 (or maybe it predates that, not sure)Probably we need to force waiting on a
fetchThreadswhen we get an event for a thread that we don't know about yet.Mercutio1243 commentedon Aug 1, 2025
Is there an update on this?
I did not face this issue last year, only now when setting up VS Code on my new laptop.
Is there a workaround such as downgrading VS Code to earlier versions to avoid this?
luishugoooo commentedon Aug 10, 2025
diegocontini commentedon Aug 16, 2025
sprite2005 commentedon Aug 25, 2025
DanTup commentedon Aug 26, 2025
roblourens Connor Peet (@connor4312) I'm unfamiliar with this code but there's a Copilot button in the sidebar so I figured I'd see what it did given the comments above.
It did this:
DanTup@8dce956
The fix seems to match your suggestion, although the test seems a bit of a mess. If this looks like the right approach, I could try to write a better test (and verify the fix against my repros above).
connor4312 commentedon Sep 8, 2025
Thanks for the nice repro 🙏
debug: fix incorrect thread state if "continued" arrives too soon aft…
debug: fix incorrect thread state if "continued" arrives too soon aft…