Debugger still broken in v1.8.0

[msweeney1999]

Does this issue occur when all extensions are disabled?: Yes/No

• VS Code Version: 1.80
• OS Version: Windows 10

Steps to Reproduce:

1. Install v1.80
2. Attempt to debug. The debugger fails to respond after the first Step request.

[VSCodeTriageBot]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.80.0. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[gjsjohnmurray]

VS Code is used to debug many languages. Which is yours?

/needsMoreInfo

[VSCodeTriageBot]

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.

Happy Coding!

[msweeney1999]

The bug is reported against the latest VS Code -- 1.80.0. I, as well as my users, had to revert back to VS Code 1.77.3 in order to debug.

I am using a DAP that I developed for the company I work for and our customers. The extension is not publicly available but has worked flawlessly until VS Code v1.79 and v1.80.

[gjsjohnmurray]

Maybe https://github.com/microsoft/vscode/issues/185785 which is about to get fixed in 1.81 Insiders.

[msweeney1999]

Thanks John,

Yes, I appreciate that the debugger issue may be resolved in the 1.81 Insiders release. However, all of my users are in corporate environments, and the suggestion to use an “Insiders” build does not go well with the IT Administrators. The same goes with similar features such as vscode.workspace.findTextInFiles, which is sorely needed by my extension, but cannot be implemented due to the Insiders requirement. And yet, this feature request has been many, many years in the waiting.

As a software developer I am somewhat disappointed in that VS Code freely promotes new releases favoring ‘enhancements’ and ‘newest feature requests’ when there are outstanding issues and bug fixes that should to be addressed to first. My opinion of course.

Sincerely, Mark

[gjsjohnmurray]

I understand your point. Meanwhile, since you are the author of the debug extension perhaps you can code a workaround as suggested by @roblourens in https://github.com/microsoft/vscode/issues/185785#issuecomment-1601337997

[Z-KN]

Maybe let me add some concrete case. Debuggers are not working in V1.80 for C/C++.

• VS Code Version: 1.80

• OS Version: Ubuntu 22.04

When I run the debugger according to the launch.json

        {
            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/build/dramsim3main",
            "args": [ "../configs/DDR4_8Gb_x8_3200.ini", "-c", "1000", "-t", "../tests/example.trace"],
            "stopAtEntry": true,
            "cwd": "${workspaceRoot}/build",
            "environment": [],
            "externalConsole": true,
            "linux": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            },
            "osx": {
                "MIMode": "lldb"
            },
            "windows": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            }
        },

Previously (on V1.77.3) it ran very well, there should be another terminal window popping up as an stdout. However, now (V1.80) after pressing F5, though there are no errors thrown, but the debugger does not start at all. No window pops up. Was able to eliminate the cause of the vscode-cpptools extension.

[roblourens]

That sounds like a different issue @Z-KN, you can bring it up with that extension.

@msweeney1999 sorry for the trouble, I am about to merge the fix but it was slow to be fixed because it was pretty late to be brought to my attention. It also comes from DAs doing something a little unusual, and can be easily worked around by the DA. That is the fastest way to get a fix.

[msweeney1999]

Thanks gentlemen,

Yes, the work-around proposed by @gjsjohnmurray works perfectly :) I am now able to use all versions of VS Code with my DAP. So, closing this issue is appropriate.

FYI ---

Perhaps the reason that this issue is cropping up is due to the sample Mock Debug tutorial sample code that many of us developers use as the template for our debugger. If you follow the code for the Mock Debug's nextRequest :

protected nextRequest(response: DebugProtocol.NextResponse, args: DebugProtocol.NextArguments): void { this._runtime.step(); this.sendResponse(response); }

Note that the this.sendResponse(response); is called last. Yet, the runtime.step() function issues a number of this.sendEvent('....'); events. It is perhaps this sequence that causes the debugger issue that is related to this post.

Thanks for all your help, Mark

[roblourens]

The mock-debug runtime also delays all sent events with a setTimeout. That got me too when I started looking at this issue. But in any case either ordering should work with the latest Insiders and the next stable release

[Z-KN]

That sounds like a different issue @Z-KN, you can bring it up with that extension.

Resolved by uninstalling the snap version and installing deb version.