Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

debug: "outside available modules" when use auto mode to debug at remote development #1677

Closed
Seumi opened this issue Aug 10, 2021 · 8 comments
Closed

debug: "outside available modules" when use auto mode to debug at remote development #1677

Seumi opened this issue Aug 10, 2021 · 8 comments
Labels
Debug Issues related to the debugging functionality of the extension. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
Debug
Milestone
v0.27.2

Comments

@Seumi
Copy link

Seumi commented Aug 10, 2021 •
edited
Loading

For asking questions, see:

Before filing an issue, please review our troubleshooting guides

Please answer these questions before submitting your issue. Thanks!

What version of Go, VS Code & VS Code Go extension are you using?

  • Run go version to get version of Go from the VS Code integrated terminal.
    • go version go1.16.7 linux/amd64
  • Run gopls -v version to get version of Gopls from the VS Code integrated terminal.
    • Build info
      golang.org/x/tools/gopls v0.7.1
      golang.org/x/tools/gopls@v0.7.1 h1:Mh3Z8Xcoq3Zy7ksSlwDV/nzQSbjFf06A+L+F8YHq55U=
      github.com/BurntSushi/toml@v0.3.1 h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ=
      github.com/google/go-cmp@v0.5.5 h1:Khx7svrCpmxxtHBq5j2mp/xVjsi8hQMfNLvJFAlrGgU=
      github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
      golang.org/x/mod@v0.4.2 h1:Gz96sIWK3OalVv/I/qNygP42zyoKp3xptRVCWRFEBvo=
      golang.org/x/sync@v0.0.0-20210220032951-036812b2e83c h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
      golang.org/x/sys@v0.0.0-20210510120138-977fb7262007 h1:gG67DSER+11cZvqIMb8S8bt0vZtiN6xWYARwirrOSfE=
      golang.org/x/tools@v0.1.6-0.20210802203754-9b21a8868e16 h1:ZC/gVBZl8poJyKzWLxxlsmhayVGosF4mohR35szD5Bg=
      golang.org/x/xerrors@v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
      honnef.co/go/tools@v0.2.0 h1:ws8AfbgTX3oIczLPNPCu5166oBg9ST2vNs0rcht+mDE=
      mvdan.cc/gofumpt@v0.1.1 h1:bi/1aS/5W00E2ny5q65w9SnKpWEF/UIOqDYBILpo9rA=
      mvdan.cc/xurls/v2@v2.2.0 h1:NSZPykBXJFCetGZykLAxaL6SIpvbVy/UFEniIfHAa8A=
  • Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.
    • 1.59.0
      379476f0e13988d90fab105c5c19e7abc8b1dea8
      x64
  • Check your installed extensions to get the version of the VS Code Go extension
    • v0.27.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

Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.

Describe the bug

When I use go mod init to initialize a module and write a simple main.go file, set a breakpoint at will, and then press F5 to start debugging. The console output：
Starting: /home/xxx/go/bin/dlv-dap dap --listen=127.0.0.1:11031 --log=true --log-dest=3
DAP server listening at: 127.0.0.1:11031
Build Error: go build -o /data00/home/xxx/go/src/xxx/tdebug/__debug_bin -gcflags all=-N -l /home/xx/go/src/xxx/tdebug
directory /home/xxx/go/src/xxx/tdebug outside available modules (exit status 1).
But when i execute this command manually(go build -o .....), the execution was successful and the file "__debug_bin" was generated.
Then i change the mode from "auto" to "exec" and specify the path of "__debug_bin", the debugging can start.

Steps to reproduce the behavior:

  1. mkdir tdebug && cd tdebug
  2. go mod init tdebug
  3. write a main.go just contains print "hello world" and make a breakpoint
  4. F5 to start debug
  5. the error occurred

Screenshots or recordings

screenshot-20210810-214028
@gopherbot gopherbot added this to the Untriaged milestone Aug 10, 2021
@Seumi
Copy link
Author

Seumi commented Aug 10, 2021

go env
Workspace Folder (tdebug): /home/xxx/tdebug
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/xxx/.cache/go-build"
GOENV="/home/xxx/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/xxx/workspace/go/pkg/mod"
GONOPROXY="xxx"
GONOSUMDB="xxx"
GOOS="linux"
GOPATH="/home/xxx/workspace/go"
GOPRIVATE="xxx"
GOPROXY="xxx"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.google.cn"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.7"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/data00/home/xxx/workspace/go/src/xxx/tdebug/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2766144329=/tmp/go-build -gno-record-gcc-switches"

@hyangah
Copy link
Contributor

hyangah commented Aug 10, 2021 •
edited
Loading

@Seumi are you using symlink? It looks like the go command and the delve runs in /data00/home/xxx/workspace/go/src/xxx/tdebug not in /home/xxx/tdebug, so the go command got confused.
Can you check if you still see the problem if you open the code from /data00/home/xxx/workspace/go/src/xxx/tdebug folder ? Thanks!

@hyangah hyangah added Debug Issues related to the debugging functionality of the extension. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Aug 10, 2021
@hyangah hyangah added this to Needs triage in Debug via automation Aug 10, 2021
@hyangah hyangah added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 10, 2021
@Seumi
Copy link
Author

Seumi commented Aug 11, 2021 •
edited
Loading

@Seumi are you using symlink? It looks like the go command and the delve runs in /data00/home/xxx/workspace/go/src/xxx/tdebug not in /home/xxx/tdebug, so the go command got confused.
Can you check if you still see the problem if you open the code from /data00/home/xxx/workspace/go/src/xxx/tdebug folder ? Thanks!

Thanks for your reply! @hyangah
Yeah, it just work when i open the project from /data00/xxx....
But i don't know why there is a "data00" here, it seem the go tool set this symlink automatically.
When i use "Locate Configured Go Tools", the go mod is "GOMOD=/data00/home/xxx..." but when i run go env in terminal, the go mod is "GOMOD=/home/xxx...", without "data00". So I want to know if this is a mechanism to go extend itself or a problem of my environment

@Seumi
Copy link
Author

Seumi commented Aug 11, 2021

It is a problem in my environment. The system image has a symlink, /home/xxx ->/data00/home/xxx, and the go tool chain doesn't seem to recognize it😢

@hyangah hyangah added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Aug 20, 2021
@hyangah hyangah modified the milestones: Untriaged, v0.27.2 Aug 27, 2021
@gopherbot
Copy link
Collaborator

Change https://golang.org/cl/346095 mentions this issue: [release] src/goDebugConfiguration: massage launch config for debug/test

@hyangah hyangah mentioned this issue Aug 30, 2021
Closed
@hyangah hyangah changed the title error "outside available modules" when use auto mode to debug at remote development debug: "outside available modules" when use auto mode to debug at remote development Aug 30, 2021
gopherbot pushed a commit that referenced this issue Aug 30, 2021
@hyangah
[release] src/goDebugConfiguration: massage launch config for debug/test
1717482 
When the current build directory is resolved to a path
different from the program's directory due to soft/symbolic links,
the go command can be confused and complain that the absolute
path in program is outside the module of the current directory.

This CL avoids such problem by making dlv always use a relative
path as the build target for build/test mode (and auto for testing).
Before starting the debug session, we massage the launch config:

  program: /foo/bar.go -> program: ./bar.go, __buildDir: /foo
  program: /foo/bar -> program: ., __buildDir: /foo/bar

Previously we find the package directory just before spawning
dlv dap and spawn the dlv dap process from the package directory.
With this CL, we find the package directory when resolving
the debug configuration before debug session.

This introduces __buildDir attribute which is internal.
(There is an ongoing work to introduce 'buildDir' to dlv DAP
so we use internal attribute to make it clear.)

Also, this made the resolveDebugConfigurationWithSubstitutedVariables
accept relative paths without workspace root. Just the behavior
is undefined. (The motivation of change in this part is
the testing. We have 'output' property or some others, that
are like relative path. I guess most users wouldn't care much.
Delve is cool with relative paths so we do our best to
resolve that wrt the workspace root.
Otherwise, just let delve decide.

Fixes #1713
Fixes #1680
Fixes #1677
Updates #1348

Change-Id: I434c43131b27d9c58058450c502e1b30c58ea690
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/344790
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/346095
@hyangah
Copy link
Contributor

hyangah commented Sep 1, 2021

v0.27.2 was released and it should fix the issue. Please reopen this issue or comment otherwise. Thanks!

@hyangah hyangah closed this as completed Sep 1, 2021
Debug automation moved this from Needs triage to Closed Sep 1, 2021
@hessonsu hessonsu mentioned this issue Sep 10, 2021
Closed
@gopherbot
Copy link
Collaborator

Change https://golang.org/cl/351272 mentions this issue: src/goDebugConfiguration: take program verbatim with external adapter

gopherbot pushed a commit that referenced this issue Sep 22, 2021
@hyangah
src/goDebugConfiguration: take program verbatim with external adapter
cfee3e1 
As a fix for #1677, the extension massages launch
configurations to start dlv from the package directory and locate
'program' to be relative from the package directory.

This heuristic does not work well if dlv dap adapter is launched
externally so dlv runs from other directory. Until `delveCWD` or
a similar mechanism that allows to control where delve runs the
build, we take the launch configuration verbatim and avoid any
mutation.

Relative paths are resolved as described in the descriptions in
package.json. This changes only the internal mechanics.

Fixes #1793

Change-Id: Ic651be25a692dbb23a51707d5ebc274f22a3c532
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/351272
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Polina Sokolova <polina@google.com>
@gopherbot
Copy link
Collaborator

Change https://golang.org/cl/351570 mentions this issue: [release] src/goDebugConfiguration: take program verbatim with external adapter

gopherbot pushed a commit that referenced this issue Sep 23, 2021
@hyangah
[release] src/goDebugConfiguration: take program verbatim with extern…
98f2fdc 
…al adapter

As a fix for #1677, the extension massages launch
configurations to start dlv from the package directory and locate
'program' to be relative from the package directory.

This heuristic does not work well if dlv dap adapter is launched
externally so dlv runs from other directory. Until `delveCWD` or
a similar mechanism that allows to control where delve runs the
build, we take the launch configuration verbatim and avoid any
mutation.

Relative paths are resolved as described in the descriptions in
package.json. This changes only the internal mechanics.

Fixes #1793

Change-Id: Ic651be25a692dbb23a51707d5ebc274f22a3c532
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/351272
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Reviewed-by: Polina Sokolova <polina@google.com>
(cherry picked from commit cfee3e1)
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/351570
Reviewed-by: Robert Findley <rfindley@google.com>
@golang golang locked and limited conversation to collaborators Sep 22, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Debug Issues related to the debugging functionality of the extension. FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
No open projects
Debug
  
Closed
Milestone
v0.27.2
Development

No branches or pull requests
3 participants
@Seumi @hyangah @gopherbot