Closed krav-la closed 3 months ago
@krav-la Thanks for the report. This is caused by v0.41.0 using Delve DAP as the default debug adapter for remote debugging.
Is it possible for you to find the remote workspace, goroot, and module cache paths? If so, can you give a try to formulate the substitutePath configuration ? e.g.
{
"name": "Connect to server",
...
"substitutePath": [
{
"from": "${workspaceFolder}", "to": "/remote/path/to/workspace",
"from": "/local/path/to/gomodcache", "to": "/remote/path/to/gomodcache",
"from": "/local/path/to/goroot", "to": "/remote/path/to/goroot",
},
]
}
/local/path/to/gomodcache
can be found with go env GOMODCACHE
.
/local/path/to/goroot
can be found with go env GOROOT
.
It will be nice if the VSCode Go extension or Delve can automate this mapping computation.
If this is too tricky, the last resort is to use the legacy debug adapter by adding "debugAdapter": "legacy"
to the configuration.
-> related issue: https://github.com/golang/vscode-go/issues/3096#issuecomment-1985839141
could you please link the two?
@krav-la Thanks for the report. This is caused by v0.41.0 using Delve DAP as the default debug adapter for remote debugging.
Is it possible for you to find the remote workspace, goroot, and module cache paths? If so, can you give a try to formulate the substitutePath configuration ? e.g.
{ "name": "Connect to server", ... "substitutePath": [ { "from": "${workspaceFolder}", "to": "/remote/path/to/workspace", "from": "/local/path/to/gomodcache", "to": "/remote/path/to/gomodcache", "from": "/local/path/to/goroot", "to": "/remote/path/to/goroot", }, ] }
/local/path/to/gomodcache
can be found withgo env GOMODCACHE
./local/path/to/goroot
can be found withgo env GOROOT
.It will be nice if the VSCode Go extension or Delve can automate this mapping computation.
If this is too tricky, the last resort is to use the legacy debug adapter by adding
"debugAdapter": "legacy"
to the configuration.
For me the legacy option didn't work. Also this fix works for my files but not the dependencies.
We have decided to revert the change of the default back to using the legacy debug adapter for remote attach in v0.41.3 to give us time to address this breakpoint issue from a lack of automated path mapping (#3193). We will try to address the broken breakpoint in the dependency in dlv dap.
Timed out in state WaitingForInfo. Closing.
(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)
Change https://go.dev/cl/580019 mentions this issue: Revert "docs: update the debugging doc about remote mode default adapter"
Change https://go.dev/cl/580422 mentions this issue: Revert "docs: update the debugging doc about remote mode default adapter"
What version of Go, VS Code & VS Code Go extension are you using?
Version Information
* Run `go version` to get version of Go from _the VS Code integrated terminal_. - go1.21.1 darwin/amd64 * Run `gopls -v version` to get version of Gopls from _the VS Code integrated terminal_. - v0.14.2 * Run `code -v` or `code-insiders -v` to get version of VS Code or VS Code Insiders. - 1.86.2 * Check your installed extensions to get the version of the VS Code Go extension - v0.41.0 * Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > `Go: Locate Configured Go Tools` command. -
Share the Go related settings you have added/edited
Didn't change any
Describe the bug
Actual behaviour:
After hitting a debug button the debugger connects to a remote app instance. Any set breakpoint is greyed out and the following message shows up
could not find file <absolute/path/to/file.go>
When the debugger reaches a break point the execution is not stopped.There are no symlinks in the project folder.
-trimpath
isn't used either.Expected behaviour
Any set breakpoint is neither greyed out nor skipped once reached during a debugging session
Steps to reproduce the behaviour:
Screenshots or recordings
If applicable, add screenshots or recordings to help explain your problem.