Empty Callstack when stopped on a breakpoint

[egamma]

Testing #26557

• Using the smoke test repository https://github.com/Microsoft/vscode-smoketest-express. With the default launch config.
• set a break point at index.js line 6
• F5
• navigate to localhost:3000
• use F11 to step quickly into the code (hold F11 pressed)

I cannot reproduce this when I set the protocol to `ínspector'

At some point the callstack section remains empty with the following exception:

Assertion failed (item already registered: stackframe:thread:530d95bc-c878-449d-aba9-78c0406026b2:1:1000): Error: Assertion failed (item already registered: stackframe:thread:530d95bc-c878-449d-aba9-78c0406026b2:1:1000)
    at Object.n [as ok] (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:4:81960)
    at t.register (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:188551)
    at new t (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:189305)
    at file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:192451
    at n.Class.define.cancel.then (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:76345)
    at s (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:192142)
    at file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:188162
    at new n.Class.derive._oncancel (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:76604)
    at e.run (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:188037)
    at t.refreshChildren (file:///C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:28:192825)
e.onUnexpectedError @ /C:/Program Files (x86)/Microsoft VS Code Insiders/resources/app/out/vs/workbench/electron-browser/workbench.main.js:29

[isidorn]

I can not reproduce this following your exact steps on the mac.
As already mentioned this issue is happening because of duplicate ids in the tree.
I checked how we are generating the ids for a stackframe and in this case it seems like two stackframes have the same frameId.
This can either happen by:

• Adapter returning same ID for multiple stack frames which should be unique by the specification of the protocol
• Adapter not respecting the startFrame, so vscode would get the frist frame, and then when asking for the rest would get the first frame again -> ending in duplication

I am suspecting the second since the assertion fails for the first stack frame in the call stack.
Since Erich only sees this for the legacy protocol I am assigning this issue to @weinand
As an alternative we can do some filtering on the vscode side to make sure the ids are unique across stack frames but let's first try to fix the root cause.

[weinand]

@isidorn I've double-checked that

• the DA doesn't return the same ID for different frames,
• the DA is respecting the startFrame (even if it would not respect the startframe, the frame IDs would be different even for identical frames).

However, frame IDs are not unique across different stop events, so they are reused after each step (like Variables IDs).
Could it be that this is a race condition?

[isidorn]

After discussing with @weinand we discovered that it can happen that VS Code frontend asks for the rest of the stack frame while a stopped event happend that VS Code is not (yet) aware of.
This results in the rest of the stack frame being newer than the top of the stack frame.

It is hard to reproduce because of the precise timing needed for this to happen.

In order to prevent this from happening we are adding more precise ids to stack frames on the VS Code side. Basically this is an index of each stack frame, since the bottom line issue happens when the top stack frame is from another time era and collides with one of the elements in the stale call stack.

To fix the real issue we are considering adding more attributes to the stack frame response such that each "time era" has its unique id, so the adapter would be aware that vscode is asking for the rest of the stack frame which became invalid in the meantime.

[weinand]

I've created a feature request against the DAP to track this issue.

[roblourens]

@isidorn I don't see how 36a00d1 fixes this, if the problem is that the stackframe id isn't unique enough. If I'm reading it right, 'index' will likely be the same across pauses?

Have an idea for how to verify?

[roblourens]

I think I can repro in Insiders with the original steps:

[isidorn]

I tried with insiders and I can not reproduce.
@roblourens looking at your screenshot you are not stopped (debug toolbar has pause action), so the call stack is supposed to be empty. It seems like an unrelated issue that you have a stale decoration in the editor (to make sure just open the developer console and you should not see the assertion errors that Erich posted in the original comment). Due to that closing.

As to why the fix fixes the issue: the issue is happening when the first stack frame gets an id from the adapter that in a previous stop some other stack frame got. To prevent this just adding the index to each stack frame fixes the issue (since it is always the top stack frame being mixed with some other non top stack frame)

@egamma can you please try to reproduce and if you still see it I will reopen

[roblourens]

I see, that makes sense. Frames in the different chunks that you request during a pause will now always have different ids. I played with this for a while and didn't see anything besides the screenshot, and when that happened, the original assert error didn't show up. So I think we can call it verified.