runtime/race: instrument Sendmsg/Recvmsg and Flock

[alberts]

What steps will reproduce the problem?

write a program that synchronizes due to calls to Sendmsg and Recvmsg

build and test with -race

What do you see instead?

a race is detected

Which compiler are you using (5g, 6g, 8g, gccgo)?

6g

Which operating system are you using?

linux

Which version are you using?  (run 'go version')

tip

Please provide any additional information below.

Dmitry helped me debug this. Recvmsg needs:

  if rsa.Addr.Family != AF_UNSPEC {
  from, err = anyToSockaddr(&rsa)
  }
+ if raceenabled && err == nil {
+ raceAcquire(unsafe.Pointer(&ioSync))
+ }

Sendmsg needs:

  msg.Iov = &iov
  msg.Iovlen = 1
+ if raceenabled {
+ raceReleaseMerge(unsafe.Pointer(&ioSync))
+ }

Dmitry suggested that this is for after Go 1.1. Since it's a small fix, it would be nice
to do it before, but we can wait.

[dvyukov]

Comment 1:

Owner changed to @dvyukov.

Status changed to Accepted.

[dvyukov]

Comment 2:

FTR, here is the change:
https://golang.org/cl/8819050/
You can fix the false positive for now, by explicitly synchronizing the state inside of
the process. I.e.
on send:
1. touch the call context
2. put the call context into a map under the mutex
3. send call id
on receive:
1. recv call id
2. find the call context in the map under the mutex
3. touch the call context
this way the call context is synchronized with the map mutex.

Labels changed: added racedetector.

[alberts]

Comment 3:

FWIW, I think what you are describing is happening in the code already, but there's
still a race detected without the fix above. So maybe there's another issue here. I'll
try to reduce the code into a snippet I can share soon.

[dvyukov]

Comment 4:

Humm.. but then it must be synchronized simply by the mutex.
Note that the more annotations we add, the more false negatives the race detector has.

[dvyukov]

Comment 5:

Sometimes I find that I was too quick making conclusions, and the race detector actually
says me completely different thing. Read the report carefully, understand what exactly
variable is involved in the race, what is the order or memory access (the first access
in the report happened last) and what are involved goroutines.

[rsc]

Comment 6:

Labels changed: added go1.3maybe.

[rsc]

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 8:

Labels changed: added repo-main.

[dvyukov]

Another case that come up is synchronization via syscall.Flock. It's effectively a mutex, so treating it as synchronization in race detector looks reasonable.

[odeke-em]

@randall77 would the work that you did in CL 205461 aka commit golang/net@2180aed#diff-d1efad72dc5b17dc66a46767c32fff40 be similar to what would solve this issue? Thanks and happy new year!