testing: data race on common.done #28169
Comments
@wselwood, could you look into this? |
I'll take a look. |
Hi @bradfitz I've taken a look I think I understand whats going on here, but I am not sure of the right way to go about fixing it. One side of the race condition is explicitly not locking, according to a comment above it. This appears to be handled the same way in the t.Fail() path. Any ideas or hints on the right way to solve this would be welcomed. I am happy to try and implement it if you can point me in the right direction, or to a person who is more likely to know the best way to solve this. |
I didn't follow the original CL. Maybe @ianlancetaylor or @mpvl have that code in their head at the moment. |
I don't think there is anything wrong with https://golang.org/cl/127596 . The testing package arranges for the race detector to report an error if there is an unsynchronized goroutine. CL 127596 introduces a new way for the race detector to notice an unsynchronized goroutine. Previously the race detector would notice an unsynchronized goroutine that calls |
Change https://golang.org/cl/142889 mentions this issue: |
Thanks @ianlancetaylor |
See https://storage.googleapis.com/go-build-log/91f20a3f/linux-amd64-race_651331f3.log
Looks like https://go-review.googlesource.com/c/127596 introduces this data race.
The text was updated successfully, but these errors were encountered: