Skip to content
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

Lock shaped_owner access in TextServerAdvanced. #76585

Closed

Conversation

rcorre
Copy link
Contributor

@rcorre rcorre commented Apr 29, 2023

Fixes #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 #32081 (comment).

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).
@rcorre rcorre requested a review from a team as a code owner April 29, 2023 17:54
@KoBeWi KoBeWi added this to the 4.1 milestone Apr 29, 2023
Copy link
Member

@bruvzg bruvzg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will essentially make TextServer single-threaded only. Providing it's TSAN messages, not an actual issues, I'm not sure if it's a good idea.

Only RID owner (not the whole TS) need to be locked for a moment when new font or text buffer is added and removed (but this in turn will need making internal structs ref counted, since it can be freed if font is reloaded in from another thread). I have attempted to implement it in #72646, but it has some performance impact on a singe threaded use.

@rcorre
Copy link
Contributor Author

rcorre commented Apr 29, 2023

Providing it's TSAN messages, not an actual issues

If TSAN can hit it, I'm pretty sure it's possible (just less likely) to hit without TSAN, so I think it's an "actual" issue in that sense. It sounds like #72646 is a better approach though, so I'll close in favor of that.

@rcorre rcorre closed this Apr 29, 2023
@rcorre rcorre deleted the textserver-lock-order-inversion branch August 20, 2023 20:18
@AThousandShips AThousandShips removed this from the 4.1 milestone Aug 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Data races when running Godot
4 participants