Repository navigation
arguments in launch.json not work in code-server #4362
Description
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
- create a project
mkdir -p code-server-debug-args
mkdir -p code-server-debug-args/.vscode- 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- create main.go
cat <<'EOF'>main.go
package main
import (
"fmt"
"os"
)
func main() {
fmt.Print(os.Args)
}
EOF- create go.mod
cat <<'EOF'>go.mod # optional
module app
go 1.15
EOF- 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
Activity
shaojunyu commentedon Oct 16, 2021
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 commentedon Oct 18, 2021
same there, downgrade to v3.11.1 solved
hxssgaa commentedon Oct 21, 2021
Encounter the same issue, please fix the error as it will impact the Python debugging as well
chrirauch commentedon Oct 29, 2021
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 commentedon Nov 1, 2021
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
DebugConfigurationProvideris invoked, and in code server I get a{}, so not even thetype,requestornameare 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 commentedon Nov 1, 2021
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 commentedon Nov 1, 2021
We'll have to see if this is still an issue after upgrading VS Code in #4414
bbrendon commentedon Dec 24, 2021
I also had to downgrade the python extension to about 1 yr old after downgrading to 3.11.1
jsjoeio commentedon Jan 3, 2022
@bbrendon have you tried in 4.0.0?
bbrendon commentedon Jan 4, 2022
@jsjoeio Negatory. I'm scared to try different versions because something new always breaks.
jsjoeio commentedon Jan 4, 2022
:/ 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 commentedon Jul 3, 2022
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.