-
-
Notifications
You must be signed in to change notification settings - Fork 880
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 safety issues detected by ThreadSanitizer #8712
Comments
#8830 solves 3 out of the 4 mentioned here, but I mostly noticed we have a new one with latest master (fix in #8831):
|
Replaces: 4c59dfb See also: OpenTTD/OpenTTD#8712
I didn't see that you were also addressing Also fixed
|
I've got a commit for the modifier key race issue here: JGRennison/OpenTTD-patches@59daa57 In theory incorrect behaviour might be able to occur if the control key state was changed at the wrong instant. |
Too slow :P I went for a slightly different approach to the problem, but looking back I am not sure I like mine. I think yours is easier .. well, except for the part where you move |
Strictly speaking, it is possible to race on |
Fair. But currently I think this setting can only be changed from the draw-thread, as it is a GUI-only routine, not? |
I think I fixed them all, at least, all the once I could easily find. After all my PRs are merged, we can do another round of testing to see if we can find any others, and update this issue accordingly :) It is funny that on the surface some look like it is a bogus message, but if you look really close, you can find a path of things going terribly wrong :P Nice :D |
Is this issue still relevant in OpenTTD 12.2? In other words, does compiling OpenTTD 12.2 with ThreadSanitizer and running give any (current/new) thread safety problems? |
The races listed here don't seem to be present any more, so this can be closed. The remaining races within OpenTTD code seem to be sound/mixer related, and can be handled separately. |
Version of OpenTTD
e1b1608
(These have been here for a long time and are not caused by the recent changes).
Expected result
No potentially problematic thread safety issues.
Actual result
ThreadSantizer output from testing e1b1608 on Linux using SDL2
I've excluded output related to PulseAudio internals.
GenWorldInfo::quit_thread is not atomic, but is modified whilst the generate world thread is running.
This is technically racy, but not likely to lead to any observable problem.
I looked into this some time ago and couldn't find a way in which this could actually lead to a deadlock.
I presume that that is still the case with the recent changes, but I haven't combed through them all yet.
IsFirstModalProgressLoop() should be called before releasing the locks, instead of after it, in DrawDirtyBlocks/HasModalProgress. The resulting sleep should still be done after releasing the locks.
(I have a commit for this, but it's heavily out of date with respect to recent changes, I can make a fresh one if you want a PR).
_cur_palette is used by both the drawing thread and the main thread so shouldn't really be modified by the main thread from within GameLoop where the locks are released.
I changed this in my branch along the lines of: JGRennison/OpenTTD-patches@4c59dfb . (This becomes a much smaller diff now that the video drivers are nicely de-duplicated :) ). I can submit a forward-ported PR of that later if this would be an acceptable mitigation.
Steps to reproduce
Build with ThreadSanitizer enabled
The text was updated successfully, but these errors were encountered: