You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Debugger sometimes get stuck in "running" state even though it's paused #2282
voidmain() {
var steps =0;
while (true) {
steps++; // Breakpoint hereprint('Has run $steps steps');
}
}
Then keep pressing F5, you'll quickly end up in a state where VS Code thinks the app is running (it has a Pause button) but it is stopped at the breakpoint.
The issue seems to be that we process the response to the resume command sent to the VM after the PauseBreakpoint event, resulting in the UI being left in the "running" state when it's actually paused.
The events in the log are in the correct order (suggesting they came from the VM in the correct order):
When we get a response to a request, we resolve/request the promise. However the code waiting on it won't be executed until we next field. If the "next message" (the PauseBreakpoint event) is already received before this, then it may be in the queue before this, and it then gets called synchronously.
Forcing a yield in the event callback (for ex `setTimeout) may resolve it, though I don't know if it may introduce other subtle timing issues. This also sounds familiar like it's come up before...
The fix was quite specific to the streamed results from the analysis server though. Until I have a better fix, I'm going to add a setTimeout(0) around the events to and get them back in the correct order.
Activity
DanTup commentedon Mar 2, 2020
When we get a response to a request, we resolve/request the promise. However the code waiting on it won't be executed until we next field. If the "next message" (the
PauseBreakpointevent) is already received before this, then it may be in the queue before this, and it then gets called synchronously.Forcing a yield in the event callback (for ex `setTimeout) may resolve it, though I don't know if it may introduce other subtle timing issues. This also sounds familiar like it's come up before...
DanTup commentedon Mar 2, 2020
We hit this before here:
#471 (comment)
The fix was quite specific to the streamed results from the analysis server though. Until I have a better fix, I'm going to add a
setTimeout(0)around the events to and get them back in the correct order.Delay processing of events in the debugger to match request responses
DanTup commentedon Mar 2, 2020
Fix seems to work in my testing, and doesn't seem to have broken anything else.
@shyndman @jensjoha if nothing breaks on CI, I'll merge this and make a new build that you can use to check it seems fixed for you too.
Delay processing of events in the debugger to match request responses
DanTup commentedon Mar 2, 2020
There's a dev build at https://github.com/Dart-Code/Dart-Code/releases/tag/v3.9.0-alpha.3 if anyone wants to try it out (you'll automatically be moved back to stable releases when the next version is released).
shyndman commentedon Mar 2, 2020
Amazing! I'll use it for the day and report back.
shyndman commentedon Mar 3, 2020
So far so good :)