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.

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

x/tools/imports: panic in (*moduleResolver).scan #30292

Closed
pwaller opened this issue Feb 18, 2019 · 7 comments
Closed

x/tools/imports: panic in (*moduleResolver).scan #30292

pwaller opened this issue Feb 18, 2019 · 7 comments
Labels
FrozenDueToAge
Milestone
Unreleased

Comments

@pwaller
Copy link
Contributor

pwaller commented Feb 18, 2019

What version of Go are you using (go version)?

$ go version
1.12rc1

Does this issue reproduce with the latest release?

I'm on x/tools commit 44bcb96. I tried reproducing on the master branch but that crashes for a different reason. I figure this stack trace will be useful anyway.

What did you do?

Using gopls with forward (note: this workflow is out of date but the new workflow doesn't work for me for unrelated reasons) under vscode.

  1. Clone https://github.com/mvdan/unparam
  2. Start typing defer foobar.Baz. at the top of main.

What did you expect to see?

Nothing, because foobar.Baz. isn't valid (I made it up).

What did you see instead?

gopls reliably crashes every time.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x80cc9e]

goroutine 35 [running]:
golang.org/x/tools/imports.(*moduleResolver).scan(0xc00cf51800, 0xc00d02bd10, 0xc00cf51800, 0xc0046111d8, 0x60d709, 0x950a60, 0xb)
	/home/pwaller/.local/src/golang.org/x/tools/imports/mod.go:205 +0x17e
golang.org/x/tools/imports.addExternalCandidates(0xc00480c360, 0xc00d02bd10, 0xc0068a0580, 0x31, 0x0, 0x0)
	/home/pwaller/.local/src/golang.org/x/tools/imports/fix.go:683 +0x9b
golang.org/x/tools/imports.fixImportsDefault(0xc00d0216c0, 0xc00d009780, 0xc0068a0580, 0x31, 0xc00d009700, 0x200, 0xc004611550)
	/home/pwaller/.local/src/golang.org/x/tools/imports/fix.go:504 +0x50c
golang.org/x/tools/imports.process(0xc0068a0580, 0x31, 0xc00063b600, 0x1e9, 0x200, 0xc004611550, 0xc00d009700, 0x4645fb, 0xc0001e6000, 0xc0001c38c0, ...)
	/home/pwaller/.local/src/golang.org/x/tools/imports/imports.go:72 +0xaa0
golang.org/x/tools/imports.Process(...)
	/home/pwaller/.local/src/golang.org/x/tools/imports/imports.go:50
golang.org/x/tools/internal/lsp/source.Imports(0xa7c4e0, 0xc0039285c0, 0xc00cd93a40, 0xc00063b600, 0x1e9, 0x200, 0xba9161, 0xba934a, 0x0, 0xc001b1e180, ...)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/source/format.go:74 +0x212
golang.org/x/tools/internal/lsp.organizeImports(0xa7c4e0, 0xc0039285c0, 0xa7b8a0, 0xc0001c38c0, 0xc004d59800, 0x38, 0xc0001813b0, 0xc000181398, 0xc003f83880, 0x57018b, ...)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/imports.go:35 +0x2d1
golang.org/x/tools/internal/lsp.(*server).CodeAction(0xc00012e500, 0xa7c4e0, 0xc0039285c0, 0xc005c78900, 0xc005c78900, 0x0, 0x0, 0x1, 0x7f0503808d98)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/server.go:340 +0xd5
golang.org/x/tools/internal/lsp/protocol.serverHandler.func1(0xa7c4e0, 0xc0039285c0, 0xc0001bde30, 0xc003fce520)
	/home/pwaller/.local/src/golang.org/x/tools/internal/lsp/protocol/server.go:283 +0x3380
golang.org/x/tools/internal/jsonrpc2.(*Conn).run(0xc0001bde30, 0xa7c520, 0xc0000b4010, 0x0, 0x0)
	/home/pwaller/.local/src/golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:327 +0x7e5
golang.org/x/tools/internal/jsonrpc2.NewConn.func4(0xc0001bde30, 0xa7c520, 0xc0000b4010)
	/home/pwaller/.local/src/golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:107 +0x51
created by golang.org/x/tools/internal/jsonrpc2.NewConn
	/home/pwaller/.local/src/golang.org/x/tools/internal/jsonrpc2/jsonrpc2.go:106 +0x261

/cc @stamblerre
@gopherbot gopherbot added this to the Unreleased milestone Feb 18, 2019
@bradfitz
Copy link
Contributor

/cc @heschik @ianthehat

@bradfitz bradfitz added NeedsFix The path to resolution is known, but the work has not been done. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 18, 2019
@gopherbot gopherbot removed the NeedsFix The path to resolution is known, but the work has not been done. label Feb 18, 2019
@heschi
Copy link
Contributor

heschi commented Feb 19, 2019

@stamblerre: I think this means that the imports code is running with GO111MODULE=on, but not in the directory that contains the go.mod file. It shouldn't panic in this case, but shouldn't gopls be running in the module directory? Or is @pwaller doing something wrong with the TCP forwarding thing?

@stamblerre
Copy link
Contributor

@pwaller: do you remember what directory you opened VSCode with? I'm having trouble reproducing this exact case, though the malformed defer statement does seem to cause the goimports logic to fail (though I only see an error message, not a panic).

@pwaller
Copy link
Contributor Author

pwaller commented Feb 20, 2019

Indeed, I cannot reproduce if I run everything in the same directory. If I run gopls from, for example, my home directory, then the crash is reproducible.

I'm opening vscode with code . from the unparam checkout.

I wasn't expecting gopls to be sensitive to where it was invoked. Is it meant to be?

@stamblerre
Copy link
Contributor

VSCode sets a "rootURI" value which we then use as the "Dir" in the packages.Config - the context for this is https://golang.org/cl/153863.

@stamblerre
Copy link
Contributor

Also, I was able to reproduce your issue at the commit you mentioned, but at tip, this situation causes a different nil pointer in diagnostics. I think ultimately the underlying issue is deciding what to do when the rootURI sent by VSCode is not valid for the file in question. /cc @ianthehat

@stamblerre
Copy link
Contributor

Duplicate of #29174

@stamblerre stamblerre marked this as a duplicate of #29174 Feb 21, 2019
@golang golang locked and limited conversation to collaborators Feb 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@bradfitz @pwaller @stamblerre @gopherbot @heschi