-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
internal/poll: data race in (*FD).SetBlocking #24481
Comments
(CC @ianlancetaylor) |
I believe the fix mentioned in #24483 would fix this one too. I am still skeptical as to whether this is a problem that real programs will encounter. |
This data race in the net package was removed as a side-effect of fixing #24942. |
Change https://golang.org/cl/119955 mentions this issue: |
Change https://golang.org/cl/123176 mentions this issue: |
Taking a read lock in SetBlocking could cause SetBlocking to block waiting for a Read in another goroutine to complete. Since SetBlocking is called by os.(*File).Fd, that could lead to deadlock if the goroutine calling Fd is going to use it to unblock the Read. Use an atomic store instead. Updates #24481 Change-Id: I79413328e06ddf28b6d5b8af7a0e29d5b4e1e6ff Reviewed-on: https://go-review.googlesource.com/123176 Run-TryBot: Ian Lance Taylor <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]> TryBot-Result: Gobot Gobot <[email protected]>
What version of Go are you using (
go version
)?go version devel +7974f0815e Mon Mar 19 21:51:23 2018 +0000 linux/amd64
This is new in 1.10.
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?What did you do?
For net:
https://play.golang.org/p/p2p0vliZwJB
For os:
https://play.golang.org/p/st7Npi4-2oQ
What did you expect to see?
With
go run -race
on that file, no leak.What did you see instead?
For os:
0f3ab149ec4
introducedSetBlocking
on file descriptors that can be pollable.SetBlocking
setsisBlocking
in a struct.SetBlocking
is not called often, but the call itself is unprotected when it is. Documentation does not suggest that the calls themselves should be protected.The text was updated successfully, but these errors were encountered: