x/tools/gopls: runtime abort in go statement

[adonovan]

#!stacks
"runtime.systemstack_switch:+4" && "runtime.newproc:+3"

Issue created by stacks.

This stack D9Rnmg was reported by telemetry:

TEXT runtime·systemstack_switch(SB), NOSPLIT, $0-0
	UNDEF
	// Make sure this function is not leaf,
	// so the frame is saved.
	CALL	runtime·abort(SB)          <--- here?  What about UNDEF??
	RET

• crash/crash
• runtime.systemstack_switch:+4
• runtime.newproc:+3
• golang.org/x/sync/errgroup.(*Group).Go:+6
• golang.org/x/tools/gopls/internal/cache.(*Snapshot).getPackageHandles.func2:+1
• golang.org/x/tools/gopls/internal/cache.(*Snapshot).getPackageHandles:+83
• golang.org/x/tools/gopls/internal/cache.(*Snapshot).forEachPackage:+37
• golang.org/x/tools/gopls/internal/cache.(*Snapshot).PackageDiagnostics:+28
• golang.org/x/tools/gopls/internal/server.(*server).diagnoseChangedFiles:+50
• golang.org/x/tools/gopls/internal/server.(*server).diagnoseSnapshot:+14
• golang.org/x/tools/gopls/internal/server.(*server).diagnoseChangedViews.func1:+3
• golang.org/x/tools/gopls/internal/server.(*server).diagnoseChangedViews.gowrap1:+16
• runtime.goexit:+0

golang.org/x/tools/[email protected] go1.23.4 linux/amd64 vscode (1)

@golang/runtime

[prattmic]

runtime.systemstack puts systemstack_switch+8 as the saved PC. That is probably in the middle of that CALL instruction. systemstack_switch shouldn't actually be getting called. I think there is just a throw while on the systemstack and we aren't collecting the systemstack frames (which would be a nice improvement)

[gabyhelp]

Related Issues

• runtime: unexpected return pc for runtime.systemstack_switch #35592 (closed)
• x/tools/gopls: out of memory (crash) #42889 (closed)
• x/tools/gopls: OOB index crash in completion.expectedReturnStmtType #70636 (closed)
• x/tools/gopls: Hover: nil deref in parseDocLink #70635 (closed)
• x/tools/gopls: sigpanic in persistent.(*mapNode).forEach #71115
• x/tools/gopls: crash due to fixed ast.Node.End beyond EOF #66790
• x/tools/gopls: analysisinternal.ZeroValue crash on (presumably) unsafe.Pointer #70585 (closed)
• x/tools/gopls: "nil handle" assert in getPackageHandles #71353
• x/tools/gopls: xrefs.Index panics after "can't fail" pgf.PosRange #70446 (closed)
• x/tools/gopls: crash in Hover (telemetry) #69362

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[findleyr]

@prattmic sorry I didn't entirely follow that--are you saying that the crash was likely somewhere in this function of the runtime, or that it could be in gopls logic?

[prattmic]

Correct, somewhere transitively called from that closure you linked to. There is a trivially user-triggerable crash here if fn is nil in go fn(), though that doesn't look possible in this case.

The other cases seem to be either out of memory, or various internal runtime assertions.

[findleyr]

Thanks. An OOM is certainly plausible.