golang / vscode-go

Go extension for Visual Studio Code
https://marketplace.visualstudio.com/items?itemName=golang.Go
Other
3.79k stars 729 forks source link

Remote debugging no longer stops at break points anymore after updating to v0.41.0 #3175

Closed krav-la closed 3 months ago

krav-la commented 4 months ago

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:

  1. Update the plugin from v0.40.3 to v0.41.0
  2. Create the following launch configuration
    {
      "name": "Connect to server",
      "type": "go",
      "request": "attach",
      "mode": "remote",
      "port": 40009,
      "host": "127.0.0.1",
      "console": "internalConsole",
      "showLog": true
    }
  3. Hit F5
  4. See how the debugger successfully connects to an app
  5. Set a break point
  6. Observe the issue

Screenshots or recordings

If applicable, add screenshots or recordings to help explain your problem.

hyangah commented 4 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.

gm0stache commented 3 months ago

-> related issue: https://github.com/golang/vscode-go/issues/3096#issuecomment-1985839141

could you please link the two?

sasklacz commented 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.

For me the legacy option didn't work. Also this fix works for my files but not the dependencies.

Screenshot 2024-03-22 at 16 23 47

suzmue commented 3 months ago

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.

gopherbot commented 3 months ago

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.)

gopherbot commented 2 months ago

Change https://go.dev/cl/580019 mentions this issue: Revert "docs: update the debugging doc about remote mode default adapter"

gopherbot commented 2 months ago

Change https://go.dev/cl/580422 mentions this issue: Revert "docs: update the debugging doc about remote mode default adapter"