Stopping due to fatal error: ProtocolException: Cannot evaluate expression on the specified stack frame.

[reasoning]

Environment

VS Code version: Code 1.67.1 (https://github.com/microsoft/vscode/commit/da15b6fd3ef856477bf6f4fb29ba1b7af717770d, 2022-05-06T12:39:22.915Z) OS version: Linux x64 5.17.5-76051705-generic Restricted Mode: No

System Info Item Value CPUs AMD Ryzen 9 5900HS with Radeon Graphics (4 x 3293) GPU Status 2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: disabled_software video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled Load (avg) 1, 1, 1 Memory (System) 15.59GB (1.04GB free) Process Argv --unity-launch --crash-reporter-id 5fbb5169-0367-4f2f-bcc4-b836ec4f5014 Screen Reader no VM 100% DESKTOP_SESSION pop XDG_CURRENT_DESKTOP Unity XDG_SESSION_DESKTOP pop XDG_SESSION_TYPE x11 Connection to 'SSH: mainframe' could not be established Canceled

Extensions (11) Extension Author (truncated) Version vscode-fix-checksums leh 1.1.0 python ms- 2022.6.2 vscode-pylance ms- 2022.5.1 jupyter ms- 2022.4.1021342353 jupyter-keymap ms- 1.0.0 jupyter-renderers ms- 1.0.6 remote-ssh ms- 0.80.0 remote-ssh-edit ms- 0.80.0 cpptools ms- 1.9.8 makefile-tools ms- 0.5.0 material-theme zhu 3.13.29 (2 theme extensions excluded)

Bug Summary and Steps to Reproduce

Bug Summary:

Steps to reproduce:

1. In this environment...
2. With this config...
3. Do '...'
4. See error...

Debugger Configurations

NA

Debugger Logs

NA

Other Extensions

No response

Additional Information

Issue Type: Bug

Debug any C++ code remote or local.

Stepping through eventually results in "Stopping due to fatal error: ProtocolException: Cannot evaluate expression on the specified stack frame."

This did not happen with the previous version(s) of vscode.

[reasoning]

https://github.com/microsoft/vscode/issues/149825

[sean-mcmanus]

@reasoning Does it repro with 1.9.8 of the C/C++ extension?

[sean-mcmanus]

@WardenGnaw Have you seen this?

[reasoning]

Its reproducible with v1.10.7, and some earlier versions.

However i have recently discovered that it may be related to the following launch.json configuration.

  "MIMode": "gdb",
  "setupCommands": [
    {
      "description": "Enable pretty-printing for gdb",
      "text": "-enable-pretty-printing",
      "ignoreFailures": true
    }
  ]

Disabling the pretty printing seems to allow the gdb debugger to properly step into functions (whereas before it was sporadic and or jumping all over the place.)

And i have not reproduced the crash after disabling the setupCommands section shown here (1 hr testing so far).

Hope that helps.

[ghost]

@reasoning Thanks for the approach which decrease the occurence. But the same issue can still happen after a long time debug working. Maybe there are some other issues should be located. This issue can reproduce easier by pressing F10 continuous and fast with some expression in watch window.

envirenment for aarch64 cross development: vscode on windows + remote development extension vscode version: 1.68.1 c/c++ extension: 1.10.7 gdb: /usr/bin/gdb-multiarch gdb version: 10.1.90.20210103-git error pic:

[sxp200422]

I have same problem in C project in windows environment, and @reasoning 's method is not help for me.

vscode version: 1.68.1版本: 1.68.1 (user setup) 提交: 30d9c6cd9483b2cc586687151bcbcd635f373630 日期: 2022-06-14T12:48:58.283Z Electron: 17.4.7 Chromium: 98.0.4758.141 Node.js: 16.13.0 V8: 9.8.177.13-electron.0 OS: Windows_NT x64 10.0.19044 c/c++ extension: 1.10.7 gdb: /usr/bin/gdb-multiarch gdb version: 10.1.90.20210103-git

The same project can be debug without error in QT Creator7.0.2, with same gdb config.

[WardenGnaw]

For those hitting that error message, can you can the following to your launch.json and share the output from the debug console?

"logging": {
   "engineLogging": true,
   "traceResponse": true
}

[sxp200422]

@WardenGnaw My launch.json after add your mentioned block is as follow

{ // 使用 IntelliSense 了解相关属性。 // 悬停以查看现有属性的描述。 // 欲了解更多信息，请访问: https://go.microsoft.com/fwlink/?linkid=830387 "version": "0.2.0", "configurations": [ { "name": "gdb", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}\build\xxx\xxx.exe", "cwd": "${workspaceRoot}", "args": [], "environment": [], "externalConsole": false, "stopAtEntry": false, "MIMode": "gdb", "miDebuggerPath": "D:\Qt\Qt5.12.9\Tools\mingw730_64\bin\gdb.exe", //minGW的gdb的绝对路径 "logging": { "engineLogging": true, "traceResponse": true }, // "setupCommands": [ // { // "description": "Enable pretty-printing for gdb", // "text": "-enable-pretty-printing", // "ignoreFailures": true,

        //     }
        // ],
    }
]

}

I tested in 2 ways.

1. Start debug without breakpoint set. The problem directly happened. See follow output of debug console: startwithoutbreakpoint.txt. startwithoutbreakpoint.txt
2. Start debug with breakpoint set, after several times attatchs the breakpoint and continue, cancel the breakpoint and continue run the program. The problem happened after continue run the problem. See follow output of debug console: startbreakpoint.txt. startbreakpoint.txt

All 2 situations above, I finally set breakpoint and vscode just show hollow grey ring as below .png.

[sxp200422]

Problem also reproduced in below environment. 版本: 1.62.3 提交: ccbaa2d27e38e5afa3e5c21c1c7bef4657064247 日期: 2021-11-17T08:11:14.551Z Electron: 13.5.2 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.19044 C/C++ Extension Pack v1.1.0

[JoshCafe]

an interesting finding: this issue canbe easily reproduced in my side with double or consecutive pressing F5 or F9/F10. That might be the reason most encoutered this issue in single step debugging.

An wordaround: wait before another strike on the keyboard.

[ZebraNorth]

This seems to be caused by the "Watch" window.

Workaround: Delete all the expressions from the watch window.

It looks like a race condition: The plugin requests the active stack frames from the debugger, then tries to evaluate the watch expressions using the top stack frame. However, before the expressions are evaluated, the debugger is stepped and the top stack frame becomes invalid.

// ... snip ...
// Request the stack - gets a response including stack frame "1030".
--> R (stackTrace-48): {"type":"response","request_seq":48,"success":true,"command":"stackTrace","body":{"stackFrames":[ snip {"id":1030,"name":"int Catch::Session::run<char>(int, char const* const*)","source":{"name":"catch_session.hpp","path":"","sources":[],"checksums":[]},"line":41,"column":1,"instructionPointerReference":"0x000055fd579caa90"},snip],"totalFrames":8},"seq":986}

// snip some steps.  It sends a few "stack-list-frames" commands but does not receive a reply.

// It tries to evaluate the watch expression "1 == 1" on stack 1030, but that function has been stepped out of.

--> E (stopped): {"type":"event","event":"stopped","body":{"reason":"step","threadId":-2,"allThreadsStopped":true,"source":{"name":"catch_run_context.cpp","path":"","sources":[],"checksums":[]},"line":444,"column":1},"seq":1085}
<--   C (evaluate-52): {"command":"evaluate","arguments":{"expression":"1 == 1","frameId":1030,"context":"watch"},"type":"request","seq":52}
Stopping due to fatal error: ProtocolException: Cannot evaluate expression on the specified stack frame.

[sxp200422]

This seems to be caused by the "Watch" window.

Workaround: Delete all the expressions from the watch window.

It looks like a race condition: The plugin requests the active stack frames from the debugger, then tries to evaluate the watch expressions using the top stack frame. However, before the expressions are evaluated, the debugger is stepped and the top stack frame becomes invalid.

// ... snip ...
// Request the stack - gets a response including stack frame "1030".
--> R (stackTrace-48): {"type":"response","request_seq":48,"success":true,"command":"stackTrace","body":{"stackFrames":[ snip {"id":1030,"name":"int Catch::Session::run<char>(int, char const* const*)","source":{"name":"catch_session.hpp","path":"","sources":[],"checksums":[]},"line":41,"column":1,"instructionPointerReference":"0x000055fd579caa90"},snip],"totalFrames":8},"seq":986}

// snip some steps.  It sends a few "stack-list-frames" commands but does not receive a reply.

// It tries to evaluate the watch expression "1 == 1" on stack 1030, but that function has been stepped out of.

--> E (stopped): {"type":"event","event":"stopped","body":{"reason":"step","threadId":-2,"allThreadsStopped":true,"source":{"name":"catch_run_context.cpp","path":"","sources":[],"checksums":[]},"line":444,"column":1},"seq":1085}
<--   C (evaluate-52): {"command":"evaluate","arguments":{"expression":"1 == 1","frameId":1030,"context":"watch"},"type":"request","seq":52}
Stopping due to fatal error: ProtocolException: Cannot evaluate expression on the specified stack frame.

I tried to delete all expression in watch windows, but the problem I mentioned below still reproduced .

[Joker-xue]

This seems to be caused by the "Watch" window.

Workaround: Delete all the expressions from the watch window.

It looks like a race condition: The plugin requests the active stack frames from the debugger, then tries to evaluate the watch expressions using the top stack frame. However, before the expressions are evaluated, the debugger is stepped and the top stack frame becomes invalid.

// ... snip ...
// Request the stack - gets a response including stack frame "1030".
--> R (stackTrace-48): {"type":"response","request_seq":48,"success":true,"command":"stackTrace","body":{"stackFrames":[ snip {"id":1030,"name":"int Catch::Session::run<char>(int, char const* const*)","source":{"name":"catch_session.hpp","path":"","sources":[],"checksums":[]},"line":41,"column":1,"instructionPointerReference":"0x000055fd579caa90"},snip],"totalFrames":8},"seq":986}

// snip some steps.  It sends a few "stack-list-frames" commands but does not receive a reply.

// It tries to evaluate the watch expression "1 == 1" on stack 1030, but that function has been stepped out of.

--> E (stopped): {"type":"event","event":"stopped","body":{"reason":"step","threadId":-2,"allThreadsStopped":true,"source":{"name":"catch_run_context.cpp","path":"","sources":[],"checksums":[]},"line":444,"column":1},"seq":1085}
<--   C (evaluate-52): {"command":"evaluate","arguments":{"expression":"1 == 1","frameId":1030,"context":"watch"},"type":"request","seq":52}
Stopping due to fatal error: ProtocolException: Cannot evaluate expression on the specified stack frame.

You are right, I cleaned all watched ,and it didn't reproduce again

[jfblazquez]

Looks like the exception is generated at GetDebugPropertyFromExpression in MIEngine project file OpenDebugAD7/AD7DebugSession.cs https://github.com/microsoft/MIEngine/blob/v1.13.1/src/OpenDebugAD7/AD7DebugSession.cs#L453

m_frameHandles does not have info about the frameId involved and fails.

Maybe GetDebugPropertyFromExpression is called before HandleStackTraceRequestAsync? Do not know, first time I see this code base.

As a Workaround: Modify the file to set property to new AD7ErrorProperty(expression, "loading...") and return from method instead of launching the ProtocolException. This way when it fails, vscode will show variables in watch window and "loading..." before it gets the good value. Edit: See comment below for a better approach

[jfblazquez]

As I saw in other HandleRequestAsync methods I added try/catch to HandleEvaluateRequestAsync. Check if FrameHandle exists in the same way as in HandleScopesRequestAsync.

Changes uploaded to https://github.com/jfblazquez/MIEngine/tree/EvaluateRequestAsyncProtocolException. @WardenGnaw feel free to contact me if you think this change may be a good PR.

[mikebeaton]

I believe the issue is caused by stepping 'too fast'.

If you press F11/F10 quickly through two or more lines of code (which you'll do eventually, when you know where you are in the code, and you know what should happen next) then you will eventually press one of them too fast, i.e. before all the results of the previous step have been fully evaluated, and this happens.

Adding a bunch of logging makes this much more likely to happen (since everything takes longer to catch up after the previous step, I guess):

            "logging": {
                "engineLogging": true,
                "trace": true,
                "traceResponse": true
            }

With logging set up as above this is very easy to replicate, in my experience.

I believe the fix may well be to force the debugger not to respond to the next (queued) F10 or F11 key until it is actually ready to.

[nwalet]

Interesting; seem to have just reached this issue yesterday, after a substantial linux OS update. Even with an "empty" tasks.json, this happens--empty watch window as well. Oh well, will run debugger outside VS code--this is unusable.

[lukester1975]

FYI looks like the 1.13.5 cpp-tools pre-release includes the miengine fix merged above. Works for me anyway (so far).