-
Notifications
You must be signed in to change notification settings - Fork 19
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
Thread race between qdr_delivery_anycast_propagate_CT and qdr_connection_process #1199
Comments
I think this is relatively benign. The race is caused by the core thread setting the settled flag in a downstream delivery at the same moment the I/O thread is checking that delivery settled flag. I think this is benign because the core will send a delivery update event to the I/O thread which will cause it to re-read the flag. Since "settled" is a latch (never goes from set to unset) this guarantees the downstream I/O thread will (eventually) see the flag's new state. This code is old as the hills, so I'm at a loss as to explain why TSAN has started to complain about it now. It may be that some recent change removed a (totally unrelated) mutex that cause TSAN to see a flush. Dunno. I'm thinking we suppress this. What do you all think? |
Update: I can repro this race locally by running the system_tests_http1_over_tcp.Http1OverTcpEdge2EdgeTest in a loop. The fickle finger 'o git-bisect points to the culprit as this commit That commit does re-arrange the codepath that exhibits this race, but I don't see it actually adding a race. I think that moving the code around a probably the reason TSAN has started complaining. Still OK with suppression. |
Yes. Say I am ok with this suppression. |
Arg - sorry I failed to notice the real reason this race is now showing up. We changed the name of the function. The old function name is used in the suppression file! We've already suppressed this error awhile back. My bad. |
The text was updated successfully, but these errors were encountered: