VS Code tries to get Call Stack data after a breakpoint resumption

[RedMickey]

• VSCode Version: 1.47.3
• OS Version: macOS 10.15.5

Hello, this is Cordova Tools team. Now we are reimplementing the debugger within the extension with vscode-js-debug usage.
While debugging some applications (e.g. Ionic Angular based) we faced such a behavior that after a breakpoint resumption VS Code sometimes opens additional tab with a source script. For example like this one:

We found out that this happens if we try to resume a breakpoint within 2-3 second after the stop. If we wait a bit more after the stop, VS Code won't open a tab with a source code after a resumption. We also found the code that handles stop events. Then we tried to debug it and revealed that for some reasons the onDidStop handler continues to work after a breakpoint resumption. In such a situation this condition becomes true (since focusedStackFrame is undefined), and then in this part of the code VS Code sends to js-debug debugger the Source request, and the debugger sends the Debugger.getScriptSource request to an application. Thus, we get a source script after a breakpoint resumption.
It seems that there might be some conflicts in async functions work and data sharing between them in js-debug.
Could you please tell us what can we do to fix it?
We can provide a demo if needed.

[isidorn]

Hi, thanks for filling this. First forwarding to @connor4312 as he owns js-debug

If you would like us to investigate more on the vscode side it would be great if you fork and make changes to mock debug so we can reproduce this issue locally https://github.com/microsoft/vscode-mock-debug

[connor4312]

@RedMickey are you able to collect a trace: true log from js-debug? That would help us clearly see the order of events here.

From what you're saying it sounds like the issue lies in the VS Code side of things with js-debug acting as a simple server responding to its requests, but the log will help us determine what's happening with greater certainty.

[RedMickey]

Hi, @connor4312, I attach logs:

• js-debug logs
• CDP proxy logs

[connor4312]

Okay, thanks. This looks like maybe a VS Code bug.

1. We get a stopped event
2. VS Code requests and we respond with the first stack frame, which exists in a file on disk
3. Immediately after VS Code asks for the rest of the stack trace, the user also requests the debugger to continue
4. We respond with the remaining stack trace.
5. Then it looks like VS Code tries to open the first frame in that trace (i.e. the second stack frame) 🐛

cc @isidorn. I can probably make some synthetic example with js-debug or mock-debug if it would be helpful

[isidorn]

@connor4312 if it is not too much effort a repro with js-debug or mock-debug would be helpful.
Alternative here's the code that fetches the callstack, there are some timeouts so I understand how an unexpected thing might happen in some corner case

vscode/src/vs/workbench/contrib/debug/common/debugModel.ts

Line 928 in a3dd5c3

topCallStack = thread.fetchCallStack(1).then(() => {

[connor4312]

Here's a branch: https://github.com/microsoft/vscode-mock-debug/tree/async-stack-ordering-bug

I tested it by using the default config with stopOnEntry 'debugging' the mock debug readme.

[isidorn]

@connor4312 thanks, assigning to me and to July so I investigate more.

[isidorn]

@connor4312 just looked into your repro, and for me it works just fine. I start debugging with stopOnEntry the readme.md in mock repository and I can properly step over statements and they get nicely rendered. Am I doing something wrong?

@RedMickey @connor4312 Also you can not repro if delayed stack trace loading is set to false, correct.

[connor4312]

Try just clicking 'continue' after you stop on the first line

[isidorn]

Thanks for the repro case.
I have pushed a fix for this. Now the stack trace will also respect CancellationTokens, which means if the user presses continue vscode will send a cancel request to the debug adapter and will ignore any late responses from the debug adapter.

I have verified that this fixes the repro case.
@RedMickey it would be great if you can also try this with latest vscode insiders from Friday (since then this should be released) and then let us know if it is ok for you. Thanks

[SounD120]

Hi @isidorn . Tested in both Mock Debug and Cordova Tools scenarios. It seems that it doesn't reproduce anymore. Thank you.

[isidorn]

@SounD120 thanks for letting us know. Adding verified label.