No "VARIABLES" when debugging GTests with Test Explorer - Debugging not working after stopping on a breakpoint

[H-G-Hristov]

Type: Debugger

Describe the bug

• OS and Version: MacOS BigSur 11.2.2
• VS Code Version: January 2021 (version 1.53)
• C/C++ Extension Version: 1.2.2
• Other extensions you installed (and if the issue persists after disabling them): C/C++ Extension Pack, C++ TestMate, Test Explorer UI, etc.

To Reproduce

Debugging Google Test Unit Tests with Google Test:

1. Set a break point
2. Start debugging by clicking the bug icon in Test Explorer.

Sometimes when the breakpoint is hit - the VARIABLES pane is empty. The Call Stack is available usually (maybe even always). Unfortunately that is all the information I could provide.

[WardenGnaw]

Which debugger are you using cppdbg or cppvsdbg and if possible can you provide logging by adding "logging": { "engineLogging": true, "trace": true, "traceResponse": true } in your launch.json

[H-G-Hristov]

@WardenGnaw I don't know about: cppdbg or cppvsdbg? How can I find that out? Also I am not quite sure where to see the expected logs? I use the default "settings" if that's correct to say.

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [],
    "logging": {
        "engineLogging": true, 
        "trace": true, 
        "traceResponse": true
     }
}

[sean-mcmanus]

In your launch.json, an "Add Configuration..." button should appear in the bottom right that you can use to create a default configuration. You should be using cppdbg. This is the gdb launch template with logging added:

{
    "version": "0.2.0",
    "configurations": [
    {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "enter program name, for example ${workspaceFolder}/a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "logging": {
                "engineLogging": true,
                "trace": true,
                "traceResponse": true
            }
        }
    ]
}

e.g. your "logging" appears to be outside of a configuration.

[H-G-Hristov]

@sean-mcmanus Thanks for the tip. I changed my launch.json to:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [

        {
            "name": "(lldb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "enter program name, for example ${workspaceFolder}/a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "lldb",
            // "logging": {
            //     "engineLogging": true,
            //     "trace": true,
            //     "traceResponse": true
            // }
        },
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "enter program name, for example ${workspaceFolder}/a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            // "logging": {
            //     "engineLogging": true,
            //     "trace": true,
            //     "traceResponse": true
            // }
        }
    ]
}

[H-G-Hristov]

I haven't experienced the described issue recently (maybe because I wasn't doing much debugging). Unfortunately as seen above I have just disabled the logging.
And just got the following, which seems that the locals are just partially displayed, incl. there is nothing in this, etc.
I am launching the debugging via the GTest extension:

So maybe this is a partial issue of the original issue?
I am not launching via Launcher because the project is a library and has just GTest unit tests.

[H-G-Hristov]

I generally experience a variety of issues when debugging on MacOS Big Sur. Like debugger shortcuts F12, F11 etc. seem to interfere with MacOS shortcuts. I don't get step in functionality, instead some MacOS functionality gets triggered.
The debugger appears to hang: clicking on the buttons Continue (F5) doesn't do anything, etc.
VisualStudioCodeBigSur.log

Yet the fan starts blowing like jet during a take-off:

[H-G-Hristov]

One way the previously described hang happens is like that:

I click on "Debug" (as seen on the Screenshot) in the Test file:

Then I click "Continue". The second breakpoint in another file (Source file) is hit:

Then regardless what I click: "Continue", "Step in", etc. the debugger appears to hang. If I click "Stop". I can place the next break point in the constructor itself and remove the second one to work around this.

Or I get a CPU meltdown again:

MeltDown.log

Note:

I can go and Force Quit these lldb-mi processes.
I am sorry about starting this issue as complaint about missing variables in the debugger pane and continuing it as generic debugger issues bug report.

[H-G-Hristov]

Today I consistently once again I experience this issue. I have attached a log.

debug.log.txt

[H-G-Hristov]

And the lldb-mi process is again using 100% CPU. This didn't happen for nearly a month.

[H-G-Hristov]

And again debugging doesn't actually work. After stopping on a breakpoint nothing but "Stop" works - continue, step, step over - don't do anything.

[H-G-Hristov]

@sean-mcmanus @WardenGnaw I noticed a pattern. If the debugging pane is opened - debugging fails. If the debugging panel is opened and I point over a variable I get to see its value. Then debugging works - I step to the next variable and if I open the debugging pane - I see the variables. Does this make any sense?

[hchxdu]

今天，我再次经历这个问题。我附上了一根圆木。

debug.log.txt

[H-G-Hristov]

Continued here: #9831