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
runtime/race: race detector sometimes misses race on []byte copy #36794
Comments
cc @dvyukov |
cc @mdempsky |
Definitely strange. It seems very fragile. Changing the string length affects it (only lengths 10 and 11 demonstrate the bug). The calls out to the race detector from the runtime look fine, and the same in both cases.
I suspect something in the race detector. Possibly this is just a limitation of the race detector, something is colliding in the shadow space in one case and not in another. It's not guaranteed to find all races. |
I suspect this is related to one of deep limitations of the tsan runtime - it memorizes at most 4 unique previous memory accesses for each 8-byte aligned granule of application memory (hard to memorize all previous memory accesses that ever happened in an application with full stack traces). When all 4 slots are already busy, tsan either replaces one of "weaker" (for purposes of race detection) memory accesses (e.g. we have a read and now a write to the same memory), or if there are no weaker ones, it replaces one pseudo-randomly. There are several aspects combined here to give this stable effect on this test:
Other range instrumentation sites should be audited for similar cases too (points 4 and 5). @rogpeppe thanks for the nice test case! False positives are worse, but they always loud and are not left unnoticed. Whereas false negatives very frequently stay unnoticed in large quantities for long time because they are silent. So each of them is way more important in some sense and always requires some manual attention and a bit healthy mistrust in things that "known to work" :) |
Yes, I noticed this as well, and swapping the order fixes this particular issue. I didn't understand why; now I do. |
Change https://golang.org/cl/220685 mentions this issue: |
What version of Go are you using (
go version
)?What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
When this test code runs under the race detector, I don't see a race detected, even though there is a race. When I add a sleep (set
bogus
to true), the race detector does find the race.https://play.golang.org/p/ECoOELB1fC1
The text was updated successfully, but these errors were encountered: