x/tools/gopls: Possible deadlock occurs between *cmdClient.filesMu
and *Server.diagnosticsMu
#56450
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.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
gopls version
golang/tools tag: gopls/v0.9.5
go env
go 1.18
What did you do?
In my use, it only happened once that there was no response for a long time, so I started to investigate.
I added pprof for gopls, and added the replacement into gopls/go.mod:
replace golang.org/x/tools => ../../tools
.Then I found out a deadlock in references, here is the full stack:(I mark the
**Step
to highlight the key layer. Goroutine 1 and 38088 provide key information.)The four steps marked above:
Step 1.a.
AddFile
lockedc.Client.filesMu
& Step 1.b.publishDiagnostics
lockeds.diagnosticsMu
Step 2.a.
AddFile
pending ons.diagnosticsMu
& Step 2.b.PublishDiagnostics
pending onc.filesMu
The deadlock happend in goroutine 1 and 38088. Goroutine 38088 created from go1: AddFile -> DidOpen -> didOpen -> didModifyFiles -> processModifications:318. BYW goroutine 38088 is created in last AddFile, but goroutine 1 is pending in currrent AddFile.
The original
tools/internal/lsp/cmd/references.go
has more than oneAddFile
call both fromargs[0]
andlocations
below. So I add mach more different locations to recurrent this. (Maybe there are other better ways?)I think such a problem can happen just by calling this
AddFile
many times quickly.In summary, before the goroutine 38088 starts, although the
go
is used to start async to ensure that the currentAddFile
releasesfileMu
through defer, but the new process has to grabfileMu
again later. So if anotherAddFile
starts soon, it will deadlock.What did you expect to see?
Get result quickly.
What did you see instead?
Endless waiting.
Editor and settings
Logs
The text was updated successfully, but these errors were encountered: