x/tools/gopls: fatal error: concurrent map iteration and map write #36006
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.
Milestone
Comments
gopherbot
added
the
Tools
|
Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here. |
|
Change https://golang.org/cl/210199 mentions this issue: |
|
Thank you for the report! Just mailed a fix for this, and I'll cherry-pick it and make a release with it ASAP. |
|
Awesome, ty! |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Dec 6, 2019
The invalidateContent function does not acquire a snapshot's mutex to avoid blocking other work (even though it probably should since it's only called after a context is canceled). A case was added to iterate through files when a file is created, and it did not respect the fact that the snapshot's mutex was not locked, resulting in a concurrent map read and write. This change makes sure that the access of the snapshot's files map is guarded by a mutex. As a follow-up, we should just acquire snapshot.mu in invalidateContent. Updates golang/go#36006 Change-Id: Idd904ae582055ce786062df50875ac7f0896fd1c Reviewed-on: https://go-review.googlesource.com/c/tools/+/210199 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
|
Change https://golang.org/cl/210203 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Dec 6, 2019
The invalidateContent function does not acquire a snapshot's mutex to avoid blocking other work (even though it probably should since it's only called after a context is canceled). A case was added to iterate through files when a file is created, and it did not respect the fact that the snapshot's mutex was not locked, resulting in a concurrent map read and write. This change makes sure that the access of the snapshot's files map is guarded by a mutex. As a follow-up, we should just acquire snapshot.mu in invalidateContent. Updates golang/go#36006 Change-Id: Idd904ae582055ce786062df50875ac7f0896fd1c Reviewed-on: https://go-review.googlesource.com/c/tools/+/210199 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> (cherry picked from commit db903f3) Reviewed-on: https://go-review.googlesource.com/c/tools/+/210203
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
Restarted gopls using
M-x lsp-workspace-restart.What did you expect to see?
A new gopls process would start without crashing.
What did you see instead?
stderrThe text was updated successfully, but these errors were encountered: