gopls: automated issue report (crash)

[nghtstr]

gopls version: v0.14.2/go1.21.4
gopls flags:
update flags: proxy
extension version: 0.40.1
environment: Visual Studio Code linux
initialization error: undefined
issue timestamp: Tue, 02 Jan 2024 01:15:35 GMT
restart history:
Tue, 02 Jan 2024 01:10:03 GMT: activation (enabled: true)
Tue, 02 Jan 2024 01:15:34 GMT: manual (enabled: true)

ATTENTION: PLEASE PROVIDE THE DETAILS REQUESTED BELOW.

Describe what you observed.

The Go PLS service would not start even after using the "Go: Restart Language Server" from VS Code.

Please attach the stack trace from the crash.

A window with the error message should have popped up in the lower half of your screen.
Please copy the stack trace and error messages from that window and paste it in this issue.

... Including File for stack trace...
stack-trace.txt

[hyangah]

Thanks for sharing the stack trace @nghtstr

Looks like the gopls panic'ed during addFolders -> snapshot.Templates.func1 call.

cc @findleyr @adonovan Can you take a look? I cannot find a similar issue in the gopls issue tracker yet.

unexpected fault address 0x0
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x80 addr=0x0 pc=0xc91e9e]

goroutine 174 [running]:
runtime.throw({0xf6adf6?, 0x65720909090a2e74?})
	/usr/lib/go/src/runtime/panic.go:1077 +0x5c fp=0xc000f21a91 sp=0xc000f21a61 pc=0x43c5bc
runtime.sigpanic()
	/usr/lib/go/src/runtime/signal_unix.go:875 +0x285 fp=0xc000f21af1 sp=0xc000f21a91 pc=0x453385
golang.org/x/tools/gopls/internal/lsp/cache.(*snapshot).Templates.func1({0x6f756769746e6f63, 0x2065657266207375}, {0x6f206e6f69676572?, 0x61706e202f2f0a66})
	/home/mike/go/pkg/mod/golang.org/x/tools/[email protected]/internal/lsp/cache/snapshot.go:331 +0x9e fp=0xc000f21af9 sp=0xc000f21af1 pc=0xc91e9e
runtime: g 174: unexpected return pc for golang.org/x/tools/gopls/internal/lsp/cache.(*snapshot).Templates.func1 called from 0x2029646572656472
stack: frame={sp:0xc000f21af1, fp:0xc000f21af9} stack=[0xc000f18000,0xc000f1a000)

created by golang.org/x/tools/gopls/internal/lsp.(*Server).addFolders in goroutine 63
	/home/mike/go/pkg/mod/golang.org/x/tools/[email protected]/internal/lsp/general.go:397 +0x64d

[hyangah]

This is another panic during addFolders, but runtime seems to get confused during traceback.

runtime: g111: frame.sp=0xc0005e3b01 top=0xc0005dbfe0
        stack=[0xc0005da000-0xc0005dc000
fatal error: traceback did not unwind completely

runtime stack:
runtime.throw({0xfb3365?, 0x0?})
        /usr/lib/go/src/runtime/panic.go:1077 +0x5c fp=0x7fd78f7fdbc8 sp=0x7fd78f7fdb98 pc=0x43c5bc
runtime.(*unwinder).finishInternal(0x0?)
        /usr/lib/go/src/runtime/traceback.go:571 +0x12a fp=0x7fd78f7fdc08 sp=0x7fd78f7fdbc8 pc=0x462cca
runtime.(*unwinder).next(0x7fd78f7fdcb0?)
        /usr/lib/go/src/runtime/traceback.go:452 +0x232 fp=0x7fd78f7fdc80 sp=0x7fd78f7fdc08 pc=0x462ad2
runtime.addOneOpenDeferFrame.func1()
        /usr/lib/go/src/runtime/panic.go:648 +0x85 fp=0x7fd78f7fde50 sp=0x7fd78f7fdc80 pc=0x43b765
traceback: unexpected SPWRITE function runtime.systemstack
runtime.systemstack()
        /usr/lib/go/src/runtime/asm_amd64.s:509 +0x4a fp=0x7fd78f7fde60 sp=0x7fd78f7fde50 pc=0x4701ca

goroutine 111 [running]:
runtime.systemstack_switch()
        /usr/lib/go/src/runtime/asm_amd64.s:474 +0x8 fp=0xc0005e3a11 sp=0xc0005e3a01 pc=0x470168
runtime.addOneOpenDeferFrame(0x78696e752f6c6c61?, 0x6e6174736e6f632f?, 0xa226f672e7374?)
        /usr/lib/go/src/runtime/panic.go:645 +0x65 fp=0xc0005e3a51 sp=0xc0005e3a11 pc=0x43b685
panic({0xe504a0?, 0x1816940?})
        /usr/lib/go/src/runtime/panic.go:874 +0x14a fp=0xc0005e3b01 sp=0xc0005e3a51 pc=0x43bf2a
runtime.panicmem(...)
        /usr/lib/go/src/runtime/panic.go:261
runtime.sigpanic()
        /usr/lib/go/src/runtime/signal_unix.go:861 +0x378 fp=0xc0005e3b61 sp=0xc0005e3b01 pc=0x453478
created by golang.org/x/tools/gopls/internal/lsp.(*Server).addFolders in goroutine 95
        /home/mike/go/pkg/mod/golang.org/x/tools/[email protected]/internal/lsp/general.go:397 +0x64d

[adonovan]

I suspect this is a compiler or runtime bug, not a bug in gopls, because of several suspicious things in the log. I've asked the compiler team to take a look, but in the meantime I suggest you build with the latest go1.22 release candidate.

[gopherbot]

Change https://go.dev/cl/553475 mentions this issue: runtime: add missing close stack bound to log

[adonovan]

@prattmic says the trace is evidence of stack corruption, and wonders whether your machine has faulty memory. Can you check whether there are recent reports of memory errors by looking in dmesg for lines of the form "memory error", or in /var/log/mcelog (or run mcelog --client) for "Hardware event"?

(I'm always wary of casting aspersions on hardware for crashes in my code, but in this case it was Michael's call!)

[prattmic]

Along a similar vane, I am curious if you also see crashes when building an older version of gopls, or using an older version of Go to build gopls?

[gopherbot]

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