Data races when running Godot #32081
Comments
|
There are lots of these errors, many of them surround the refcount primitive. I recommend reading this excellent article for some background on data races, and to understand why even "benign-looking" code often isn't benign: https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong. |
|
Here is also another great reference from the thread sanitizer docs: https://github.com/google/sanitizers/wiki/ThreadSanitizerPopularDataRaces |
|
When running my game with Godot 3.2.2, there is a lot of more errors - Thread Sanitizer Log.txt Strange that this happens a lot with |
One issue there is that both the read and the write must be atomic or otherwise synchronized. See the language in the error messages, e.g. ("Atomic write" vs "previous read"). One of the warnings indicates for example that Lines 101 to 109 in b96b0d9 I refer also again to https://software.intel.com/content/www/us/en/develop/blogs/benign-data-races-what-could-possibly-go-wrong.html -- I think this is actually one of the examples given in that blog post of a "what could possibly go wrong", at the end. |
|
I have plans to address much of these issues very soon. I'll fix all the wrong approaches to atomicity in 4.0 and then port them to 3.2. My expectation is that we'll get rid of a number of hard to debug issues that stem from that. Please stay tuned. 😄 |
|
When running https://github.com/qarmin/RegressionTestProject/tree/3.2, then there is still huge amount of data races - 7_Use Godot.txt in 3.2.4.beta.custom_build. ebe9d61 |
|
Is this still reproducible in latest 4.x builds? |
|
After patching around #76581, I see a lot of |
|
The main pattern I'm seeing is in
|
rcorre
added a commit
to rcorre/godot
that referenced
this issue
Apr 29, 2023
Fixes godotengine#32081. _free_rid takes the THREAD_SAFE_METHOD lock first, then locks FontAdvanced::mutex second. Many functions lock FontAdvanced::mutex first, then call _shaped_text_shape which takes the THREAD_SAFE_METHOD lock second. TSAN flags this as "lock-order-inversion (potential deadlock)". As _shaped_text_shape and _free_rid seem to call THREAD_SAFE_METHOD to guard access to the shaped_owner method, I'm assuming that other methods accessing shaped_owner also ought to take a lock. Doing this ensures that the locks are always taken in a consistent order, avoiding a deadlock between _free_rid and the various _shaped_text_* functions. The full TSAN output can be found at godotengine#32081 (comment).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Godot version:
3.2.alpha.custom_build. 24e1039
OS/device including version:
Ubuntu 19.04
Issue description:
When I run Godot project manager, then thread sanitizer shows some data races(reading data in one thread, when saving in another thread)
Steps to reproduce:
The text was updated successfully, but these errors were encountered: