x/tools/gopls: Completion: SIGSEGV in scorePenalty

[adonovan]

#!stacks
"sigpanic"&& "completion.(*deepCompletionState).scorePenalty:+2"

Issue created by stacks.

// scorePenalty computes a deep candidate score penalty. A candidate is
// penalized based on depth to favor shallower candidates. We also give a
// slight bonus to unexported objects and a slight additional penalty to
// function objects.
func (s *deepCompletionState) scorePenalty(cand *candidate) float64 {
	var deepPenalty float64
	for _, dc := range cand.path { <-- sigpanic
		deepPenalty++

		if !dc.Exported() {
			deepPenalty -= 0.1
		}

		if _, isSig := dc.Type().Underlying().(*types.Signature); isSig {
			deepPenalty += 0.1
		}
	}

	// Normalize penalty to a max depth of 10.
	return deepPenalty / 10
}

This stack AZThiA was reported by telemetry:

• crash/crash
• runtime.gopanic:+69
• runtime.panicmem:=262
• runtime.sigpanic:+19
• golang.org/x/tools/gopls/internal/golang/completion.(*deepCompletionState).scorePenalty:+2
• golang.org/x/tools/gopls/internal/golang/completion.(*completer).addCandidate:+37
• golang.org/x/tools/gopls/internal/golang/completion.(*completer).deepSearch:+71
• golang.org/x/tools/gopls/internal/golang/completion.Completion:+158
• golang.org/x/tools/gopls/internal/server.(*server).Completion:+19
• golang.org/x/tools/gopls/internal/protocol.serverDispatch:+193
• golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5
• golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.handshaker.func4:+52
• golang.org/x/tools/gopls/internal/protocol.Handlers.MustReplyHandler.func1:+2
• golang.org/x/tools/gopls/internal/protocol.Handlers.AsyncHandler.func2.2:+3
• runtime.goexit:+0

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

[adonovan]

On the surface this looks like a nil dereference, but there's no way that a nil candidate value can reach this point. Furthermore, the dominating statements not only dereference the pointer but load fields at both lower and higher offsets than cand.path (such as c.obj and c.mods), so this can't be explained by cand being a pointer to bad memory near the bottom or top of a mapping (even though that would itself be very weird).

Even if the stack reporting was off by one, there is no plausible explanation on an adjacent line. The only thing that comes to mind is either a runtime bug or a hardware fault. Most unsatisfactory.

cc: @prattmic

[gabyhelp]

Related Issues

• x/tools/gopls: OOB index crash in completion.expectedReturnStmtType #70636 (closed)
• x/tools/gopls: completion: failed type assertion in inferExpectedTypeArg #70889 (closed)
• x/tools/gopls: nil Signature (?) deref in Completion #70634 (closed)
• x/tools/gopls: Completion: failed type assertion in completer.item #71044 (closed)
• x/tools/gopls: analysisinternal.ZeroValue crash on (presumably) unsafe.Pointer #70585 (closed)
• x/tools/gopls: crash in Hover (telemetry) #69362
• x/tools/gopls: failed *types.Func type assertion in populateCommentCompletions #71273 (closed)
• x/tools/gopls: CodeAction: nil panic in findMatchingDiagnostics #71028 (closed)
• x/tools/gopls: Completion: "ZeroString for unexpected type" panic #70744 (closed)
• x/tools/gopls: stubmethods: nil deref of FuncType.Results in fromReturnStmt #70967 (closed)

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

[findleyr]

This came from the same report as #71177, which is similarly inexplicable. In both cases, it was a one-off report.
That seems to be sufficient evidence of faulty hardware.
There may still be a data race, but that is tracked by #71425.
Therefore, closing this as unactionable (and likely a red herring).