-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
x/net/internal/socket: race detector not detecting ipv4.PacketConn.ReadFrom as writer #35329
Comments
My guess is that there is some internal synchronization in |
I’m somehow ending up in What did make the race detector trigger, though, was not passing the buffer directly to the syscall but allocating a temporary one for the diff --git a/ipv4/payload_cmsg.go b/ipv4/payload_cmsg.go
index e761466..7250ae5 100644
--- a/ipv4/payload_cmsg.go
+++ b/ipv4/payload_cmsg.go
@@ -27,10 +27,12 @@ func (c *payloadHandler) ReadFrom(b []byte) (n int, cm *ControlMessage, src net.
c.rawOpt.RUnlock()
switch c.PacketConn.(type) {
case *net.UDPConn:
- m.Buffers = [][]byte{b}
+ buf := make([]byte, len(b), cap(b))
+ m.Buffers = [][]byte{buf}
if err := c.RecvMsg(&m, 0); err != nil {
return 0, nil, nil, &net.OpError{Op: "read", Net: c.PacketConn.LocalAddr().Network(), Source: c.PacketConn.LocalAddr(), Err: err}
}
+ copy(b, buf)
case *net.IPConn:
h := make([]byte, HeaderLen)
m.Buffers = [][]byte{h, b} Is it maybe the syscall in combination with the scatter-gather iovec that is masking the write? |
After digging through how I think |
Ok, I can reproduce by putting a @dvyukov : What is the right way to tell the race detector about reads and writes done by a syscall? |
go/src/syscall/syscall_unix.go Line 192 in 3c0fbee
|
Change https://golang.org/cl/205461 mentions this issue: |
I can confirm that this CL fixes the issue for me and the race detector now also reports the bug in my non-test program correctly. Thanks for the quick reponse! 🙂 |
Hi,
I’ve been tracking down a race condition in my code that was caused by sharing a []byte buffer (or a subslice of it) between one
"golang.org/x/net/ipv4".(*PacketConn).ReadFrom
reader goroutine and another one processing it. I was surprised by the race detector not complaining about this at all, it seems like the ReadFrom isn’t detected as a writer to that buffer(’s data).The same buffer sharing misuse is being reported when I use a plain
copy()
instead. Below are two test cases.What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes (tested with go.13.4 on arm64).
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Incorrectly sharing a []byte buffer between goroutines and running
go test -race
. Here’s the sample test code, the first goroutine sends "1\n" through "9\n" in 10ms intervals through UDP localhost:1234. The second goroutine receives this data from a listening socket to a buffer, sending buf[:1] over a channel to the main goroutine that receives in 20ms intervals:What did you expect to see?
The tests failing and the race detector detecting a race, such like in this example that uses a plain
copy()
instead ofPacketConn.ReadFrom
:What did you see instead?
Just the tests failing, the race detector not having any issues.
The text was updated successfully, but these errors were encountered: