Debugger: Windows cmd usage as a pipe program in case of not English characters send

[viewizard]

Note, this is not a omnisharp-vscode bug, but question.

We are developing .Net debugger and got Samsung/netcoredbg#29 issue.
The point of issue - if netcoredbg used with VSCode and use Windows "cmd" as a pipe program, in case of not-English variables (evaluation requests by VSCode protocol), we have issue with corrupted data, that was sent to debugger.

In case of variable with name "당신":
Header Content-Length: 127
But data itself corrupted ("??" instead of "당신"), bytes that was read by debugger:

{"command":"evaluate","arguments":{"expression":"??","frameId":88201448390656,"context":"hover"},"type":"request","seq":13}

and received data block have only 123 bytes.
In case of variable with name "你":
Header Content-Length: 124
Bytes that was read by debugger:

{"command":"evaluate","arguments":{"expression":"?","frameId":59270548684800,"context":"hover"},"type":"request","seq":13}

and data block have only 122 bytes.

I tested with vsdbg.exe, and it works fine with default configuration, but if I add to default configuration pipe

"pipeTransport": {
                "pipeCwd": "${workspaceFolder}",
                "pipeProgram": "cmd",
                "pipeArgs": ["/c"],
                "debuggerPath": "C:\\Users\\viewizard\\.vscode\\extensions\\ms-dotnettools.csharp-1.22.1\\.debugger\\vsdbg.exe"
            }

vsdbg.exe have same issue during not English variables evaluation (in the same place as netcoredbg have) with error:

Error: Invalid protocol message received. Aborting the debug session.

Could you please share, how you start vsdbg.exe? Do you change encoding/codepage for cmd, or you have some pipe program and don't use cmd at all?

[gregg-miskelly]

In the cmd.exe case, I believe the problem is that cmd.exe is using the default console code page, but the DAP expects UTF8. I believe you could fix it by changing pipeArgs to ["/C", "chcp", "65001", "&"]. Arguably vsdbg-ui should be doing this before starting the pipe program so that if the pipe program respects the console code page it will get the correct output.

[viewizard]

In the cmd.exe case, I believe the problem is that cmd.exe is using the default console code page, but the DAP expects UTF8. I believe you could fix it by changing pipeArgs to ["/C", "chcp", "65001", "&"].

I also tested this, unfortunately, this don't fix the issue. In this case, I still see broken vscode packages, but in this case all non-English characters replaced by zero, instead of '?'. I mean, with code page 65001 cmd/conhost.exe convert all utf-8 symbols (in my case with 3 bytes each) into 1 byte filled by zero. I found in internet, that Windows cmd/conhost.exe don't really support utf-8. This looks like in order to use our debugger with VSCode we are forced to also provide pipe program...

But, is the any way to start local debugger directly, without any additional pipe program?

[gregg-miskelly]

I am not sure I understand your question. Are you trying to use the C# extension's debugger to debug the Samsung debugger? Why are using using cmd as a pipe program?

[viewizard]

Are you trying to use the C# extension's debugger to debug the Samsung debugger?

No, I am testing netcoredbg usage as C# debugger with VSCode/VSCodium instead of vsdbg. Usually, we use it with VSCode/VSCodium on Linux only, but now we have issues from people, who use netcoredbg as C# debugger with VSCode/VSCodium on Windows.

Why are using using cmd as a pipe program?

People from our initial issues use netcoredbg with Windows VSCode in this way (with cmd as a pipe program).
Frankly speaking, I don't see how we could use netcoredbg as local C# debugger with VSCode C# extension in another way (without pipe program), from another side, we don't provide pipe program like vsdbg-ui.

[gregg-miskelly]

Are you saying that netcoredbg doesn't register its own debug adapter type but instead folks will leave type as coreclr and set netcoredbg as debuggerPath with pipe program?

If so, that was never an intentional feature. Netcoredbg should really register its own debugger type.

[viewizard]

Are you saying that netcoredbg doesn't register its own debug adapter type but instead folks will leave type as coreclr and set netcoredbg as debuggerPath with pipe program?

Yes, this looks like this in launch.json:

        {
            "name": ".NET Core Launch with netcoredbg",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "program": "${workspaceFolder}/bin/Debug/netcoreapp3.1/VSCodeTestEvalNotEnglish.dll",
            "args": [],
            "cwd": "${workspaceFolder}",
            "console": "integratedTerminal",

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

            "pipeTransport": {
                "pipeCwd": "${workspaceFolder}",
                "quoteArgs": false,
                "pipeProgram": "cmd",
                "pipeArgs": ["/c"],
                "debuggerPath": "D:\\projects\\netcoredbg\\bin\\netcoredbg.exe"
            }
        }

For Linux - same idea. Usually we don't have any issues, since use same vscode protocol as vsdbg.

If so, that was never an intentional feature. Netcoredbg should really register its own debugger type.

Ohhh... I thought...

[gregg-miskelly]

Got it. So I am going to close this issue then. The right way to solve this would be to add a new netcordbg (or whatever folks want to call it) debug adapter type.