arguments in launch.json not work in code-server

[aiziyuer]

OS/Web Information

• Web Browser: Google Chrome 92.0.4515.159
• Local OS: Windows 10 Professional Workstation Edition 21H1
• Remote OS: Red Hat Enterprise Linux release 8.4 (Ootpa)
• Remote Architecture: x86_64
• code-server --version: 3.12.0 b37ff28

Steps to Reproduce

1. create a project

mkdir -p code-server-debug-args
mkdir -p code-server-debug-args/.vscode

2. create launch.json(the arguments is myargs)

cat <<'EOF'>.vscode/launch.json
{
    "configurations": [
        {
            "name": "Launch Package",
            "type": "go",
            "request": "launch",
            "mode": "auto",
            "program": "${fileDirname}",
            "args": [
                "myargs"
            ]
        }
    ]
}
EOF

3. create main.go

cat <<'EOF'>main.go
package main

import (
	"fmt"
	"os"
)

func main() {
	fmt.Print(os.Args)
}
EOF

4. create go.mod

cat <<'EOF'>go.mod # optional
module app

go 1.15
EOF

5. debug in code-server

the project above can be download on https://github.com/aiziyuer/code-server-debug-args.

Expected

the test program shoud output my args myargs

[/tmp/__debug_bin458249886 myargs]

Actual

Case 01: go run

➜  code-server-debug-args git:(master) ✗ go run main.go myargs
[/tmp/go-build412015233/b001/exe/main myargs]

Case 02: debug in vscode(remote ssh)

Starting: /root/go/bin/dlv-dap dap --check-go-version=false --listen=127.0.0.1:41885 --log-dest=3 from /opt/code-server-debug-args
DAP server listening at: 127.0.0.1:41885
[/tmp/__debug_bin458249886 myargs]

Case 03: debug in code-server

Starting: /root/go/bin/dlv-dap dap --check-go-version=false --listen=127.0.0.1:33611 --log-dest=3 from /opt/code-server-debug-args
DAP server listening at: 127.0.0.1:33611
[/tmp/__debug_bin3637673742]

Logs

Screenshot

Notes

This issue can be reproduced in VS Code: Yes

[shaojunyu]

I recently came across the same issue in my code-server (Version: 3.12.0 on Ubuntu 18.04). The lanch.json file seems doesn't work while debugging the Python code. The same problem also happened for this version when I tested the code-server on MacOS. But after I downgraded the code-server to Version 3.11.1, this issue was solved, which works for Linux and MacOS.

[ianquu]

same there, downgrade to v3.11.1 solved

[hxssgaa]

Encounter the same issue, please fix the error as it will impact the Python debugging as well

[chrirauch]

same here with php debugging... launch.json seems to be ignored. As a workaround, instead of downgrading, i added the launch configuration directly in the server settings.json

[pablocabrera85]

Hi. We are affected by an issue that might be related to this.

In our case, it is not like the configuration values are not resolved, but it seems like that the entire configuration object is empty. It doesn't take into account the selected run configuration.
I have tried logging the entire object when our DebugConfigurationProvider is invoked, and in code server I get a {}, so not even the type, request or name are solved.
When we create the entire configuration object (with arguments, no need to hardcode the values), the arguments are resolved and the debugger starts.

[pablocabrera85]

Also, even when having multiple configurations in the launch.json file and no file selected, it asks the users which debug configuration they want to use, and suggests all installed debuggers, instead of the available ones

[jsjoeio]

We'll have to see if this is still an issue after upgrading VS Code in #4414

[bbrendon]

I also had to downgrade the python extension to about 1 yr old after downgrading to 3.11.1

[jsjoeio]

@bbrendon have you tried in 4.0.0?

[bbrendon]

@jsjoeio Negatory. I'm scared to try different versions because something new always breaks.

[jsjoeio]

I'm scared to try different versions because something new always breaks.

:/ we're hoping to get things more stable with the next release. It's a major release so expect some breaking changes, but moving forward, it should get better.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.