runtime/race.TestRace runs a collection of tests in runtime/race/testdata, with the expectation that some pass and some fail due to data races.
TestRaceRangeFuncIterator (https://go.googlesource.com/go/+/refs/tags/go1.24.0/src/runtime/race/testdata/rangefunc_test.go#67) is currently terminating the test run due to a "range function continued iteration after loop body panic" error. Tests after this one don't run.
Comment From: randall77
Should we change runtime.panicrangestate to do something different when the race detector is on?
(Report a "race" instead of panicking?)
Comment From: neild
Related: TestNoRaceRangeFuncIterator (the next test in line) fails with an unexpected data race. The failure wasn't showing up due to the previous test terminating the entire run.
Comment From: neild
I think the race detector isn't relevant to the panic (although I might be mistaken).
These tests range over a func that starts two goroutines which simultaneously yield values. The "range func continued iteration after loop body panic" happens when the range loop breaks early.
This seems to happen even if the loop body doesn't panic. I think we're incorrectly producing an "...after loop body panic" error when it should be "...after loop body exited".
We also seem to be detecting a data race when a rangefunc's yield is called concurrently. TestNoRaceRangeFuncIterator expects this to work, but perhaps the test is out of date?
Comment From: gopherbot
Change https://go.dev/cl/658875 mentions this issue: runtime/race: detect when TestRace fails to run all tests, skip failures
Comment From: AndrewHarrisSPU
We also seem to be detecting a data race when a rangefunc's yield is called concurrently. TestNoRaceRangeFuncIterator expects this to work, but perhaps the test is out of date?
It does seem like splicing the linked list of defers involved in a range function could be racy in the general circumstance? I'm probably well out of my depth and not sure if this is what's detected by the race detector, but, like map writes, detecting the race is a little different from observing an unexpected outcome ... in this case I think it's fair to observe that yield is being raced.
Comment From: mknyszek
CC @dr2chase
Comment From: mknyszek
In triage, we think we need to leave this bug open until we can re-enable the tests.
Comment From: dr2chase
Why not fix the test to catch the panic and continue? The rangefunc checking are designed to (often) blow up if the yield function is run in parallel. I.e., this is working-as-intended.