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/gopls: panic in go/types #45434

Closed
brunetto opened this issue Apr 7, 2021 · 6 comments
Closed

x/tools/gopls: panic in go/types #45434

brunetto opened this issue Apr 7, 2021 · 6 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
Unreleased

Comments

@brunetto
Copy link

brunetto commented Apr 7, 2021

gopls version: v0.6.9
gopls flags:
update flags: proxy
extension version: 0.24.0
go version: 1.16.3
environment: Visual Studio Code darwin
initialization error: undefined
manual restart count: 0
total start count: 1

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

It seems I was defining a type as pointer to an imported type but the type name was the same as the imported package.

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

goroutine 5805 [running]:
go/types.(*Checker).handleBailout(0xc007f30ea0, 0xc00840f808)
	  check.go:245  0x9f
panic(0x190cd00, 0x1fb8350)
	  panic.go:965  0x1b9
go/types.IsInterface(...)
	  predicates.go:76
go/types.(*Checker).rawLookupFieldOrMethod(0xc007f30ea0, 0x1b57338, 0xc00323dcc0, 0xc004975400, 0xc007f6a500, 0xc007f02910, 0x5, 0x0, 0x1, 0x5, ...)
	  lookup.go:86  0x11a8
go/types.(*Checker).lookupFieldOrMethod(0xc007f30ea0, 0x1b57310, 0xc007f6b680, 0xc0052b2500, 0xc007f6a500, 0xc007f02910, 0x5, 0xd5557fb5555fe, 0x34, 0x20, ...)
	  lookup.go:58  0x165
go/types.(*Checker).selector(0xc007f30ea0, 0xc004975440, 0xc007ef8cc0)
	  call.go:433  0x151
go/types.(*Checker).typInternal(0xc007f30ea0, 0x1b62db0, 0xc007ef8cc0, 0x0, 0x10, 0x1926720)
	  typexpr.go:237  0x6f0
go/types.(*Checker).definedType(0xc007f30ea0, 0x1b62db0, 0xc007ef8cc0, 0x0, 0x0, 0x0)
	  typexpr.go:138  0x55
go/types.(*Checker).typ(...)
	  typexpr.go:120
go/types.(*Checker).typInternal(0xc007f30ea0, 0x1b62e40, 0xc007ef8cd8, 0xc007f6b680, 0x48, 0x199e080)
	  typexpr.go:279  0x925
go/types.(*Checker).definedType(0xc007f30ea0, 0x1b62e40, 0xc007ef8cd8, 0xc007f6b680, 0x0, 0x0)
	  typexpr.go:138  0x55
go/types.(*Checker).typeDecl(0xc007f30ea0, 0xc007f6a780, 0x1b62e40, 0xc007ef8cd8, 0x0, 0x0)
	  decl.go:648  0x22e
go/types.(*Checker).objDecl(0xc007f30ea0, 0x1b75608, 0xc007f6a780, 0x0)
	  decl.go:192  0x7e6
go/types.(*Checker).packageObjects(0xc007f30ea0)
	  resolver.go:537  0x3a9
go/types.(*Checker).checkFiles(0xc007f30ea0, 0xc007d4cd50, 0x1, 0x1, 0x0, 0x0)
	  check.go:265  0xb9
go/types.(*Checker).Files(...)
	  check.go:250
golang.org/x/tools/internal/lsp/cache.typeCheck(0x1b64598, 0xc005c25480, 0xc0004c1110, 0xc000fb6e00, 0x2, 0xc0011aa120, 0x0, 0x0, 0x0)
	  check.go:431  0x1193
golang.org/x/tools/internal/lsp/cache.(*snapshot).buildPackageHandle.func1(0x1b64598, 0xc005c25480, 0x1b52e40, 0xc0004c1110, 0xc00051e740, 0x2)
	  check.go:101  0x1bc
golang.org/x/tools/internal/memoize.(*Handle).run.func1(0xc00445fec0, 0x1b64598, 0xc005c25480, 0xc000ceb920, 0x1b52e40, 0xc0004c1110, 0xc00119f6e0)
	  memoize.go:322  0xab
created by golang.org/x/tools/internal/memoize.(*Handle).run
	  memoize.go:315  0x185
[Error - 7:01:37 PM]
@stamblerre
Copy link
Contributor

Thanks for reporting this issue! It looks like the nil pointer happens here, but I think this has actually been fixed at master (

go/src/go/types/type.go

Line 881 in fca51ba

func under(t Type) Type {
).

/cc @findleyr for confirmation

@findleyr
Copy link
Contributor

findleyr commented Apr 7, 2021

Thanks for the report, this is interesting. I would not be surprised if this has been fixed, but also that code should not panic. If I understand your description, you were doing something like this:

type foo *foo.Bar

Is that correct?

CC @griesemer

@stamblerre stamblerre transferred this issue from golang/vscode-go Apr 7, 2021
@gopherbot gopherbot added the gopls Issues related to the Go language server, gopls. label Apr 7, 2021
@stamblerre stamblerre changed the title gopls: automated issue report (crash) x/tools/gopls: panic in go/types Apr 7, 2021
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Apr 7, 2021
@gopherbot gopherbot added this to the Unreleased milestone Apr 7, 2021
@griesemer
Copy link
Contributor

The specific code pattern:

type foo *foo.Bar

doesn't cause a panic (neither in go/types nor the compiler, nor types2). I also tried

package p

import "fmt"

type fmt *fmt.Stringer

for good measure, and we also get the expected error repors.

We'd need more info to reproduce this crash, I think.

@brunetto
Copy link
Author

brunetto commented Apr 7, 2021

Hi,
I tried this and I got a gopls crash immediately:

package main

func main() {}

type fmt *fmt.Stringer

What more info can I provide to help?

@griesemer
Copy link
Contributor

Whatever the bug was in the type checkers, this is not reproducible at tip.

@stamblerre
Copy link
Contributor

Thanks for confirming that, @griesemer.
Looks like the fix will be available when Go 1.17 is released. Sorry about the inconvenience!

@golang golang locked and limited conversation to collaborators Apr 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
5 participants
@brunetto @stamblerre @griesemer @gopherbot @findleyr