-
Notifications
You must be signed in to change notification settings - Fork 28.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Empty Callstack when stopped on a breakpoint #27694
Comments
I can not reproduce this following your exact steps on the mac.
I am suspecting the second since the assertion fails for the first stack frame in the call stack. |
@isidorn I've double-checked that
However, frame IDs are not unique across different stop events, so they are reused after each step (like Variables IDs). |
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. 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. |
I've created a feature request against the DAP to track this issue. |
I tried with insiders and I can not reproduce. 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 |
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. |
Testing #26557
I cannot reproduce this when I set the protocol to `ínspector'
At some point the callstack section remains empty with the following exception:
The text was updated successfully, but these errors were encountered: