x/tools/gopls: "negative WaitGroup counter" panic in diagnoseChangedViews

[adonovan]

#!stacks
"runtime.gopanic" && "sync.(*WaitGroup).Add:+19" && "diagnoseChangedViews.func1:+16`"

Issue created by stacks.

func (wg *WaitGroup) Add(delta int) {
...
	state := wg.state.Add(uint64(delta) << 32)
	v := int32(state >> 32)
	w := uint32(state)
...
	if v < 0 {
		panic("sync: negative WaitGroup counter") // <---------- here
	}

This stack OKWeGA was reported by telemetry:

• crash/crash
• runtime.gopanic:+69
• sync.(*WaitGroup).Add:+19
• sync.(*WaitGroup).Done:=89
• golang.org/x/tools/gopls/internal/server.(*server).diagnoseChangedViews.func1:+16
• golang.org/x/tools/gopls/internal/server.(*server).diagnoseChangedViews.gowrap1:+16
• runtime.goexit:+0

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

[adonovan]

I can't explain this. Calls to Add and Done are strictly paired and the Done always happens after the Add. There are no other salient uses of the WaitGroup.

Paging compiler and runtime folks. @prattmic

[gabyhelp]

Related Issues

• x/tools/gopls: CodeAction: nil panic in findMatchingDiagnostics #71028 (closed)
• x/tools/gopls: xrefs.Index panics after "can't fail" pgf.PosRange #70446 (closed)
• x/tools/gopls: crash when primary diagnostics have invalid positions #66731 (closed)
• x/tools/gopls: crash in Hover (telemetry) #69362
• x/tools/gopls: analysisinternal.ZeroValue crash on (presumably) unsafe.Pointer #70585 (closed)
• gopls: automated issue report (crash) #70247 (closed)
• x/tools/gopls: index out of range panic with v0.3.4 #37977 (closed)
• x/tools/gopls: automated issue report (crash) #66174 (closed)
• x/tools/gopls: panic in token.File.Name within PackageDocHTML (telemetry) #70149 (closed)
• x/tools/gopls: OOB index panic after parsing go list error from file with //line directives #67360 (closed)

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

[prattmic]

I agree, this use of WaitGroup looks straightforward and bug free to me.

[adonovan]

I think the symptom must indicate one of these causes:

• the WaitGroup counter overflowed, which is impossible because the length of the range slice is never more than a small handful;
• wg.Done was called before the completion of its corresponding Add, which is impossible in a correct translation of the program;
• the heap-allocated local variable wg was clobbered by software: this indicates either general memory corruption, or a bug in the runtime (e.g. GC);
• a hardware fault, e.g. bad RAM, or a cosmic ray shower flipped the sign bit of the semaphore.

[findleyr]

I don't know what to do with this, so moving it to the backlog rather than next release milestone.

[adonovan]

I think we should send it to the runtime folks, since there's nothing we can do in gopls.

[findleyr]

This came from the same report as #71355, 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).