ThreadSanitizer: data race in ViewLayer.forceRender.setter #3827
Assignees
Labels
Comments
low-batt
changed the title
low-batt
added a commit
that referenced
this issue
Oct 12, 2022
This commit will: - Change VideoLaye.draw to queue a task to the mpvGLQueue queue - Change MPVController.mpvUpdateCallback to call draw directly - Change MainWindowController.enterInteractiveMode to call draw directly - Change mpvGLQueue to be a private constant These changes cause all drawing to occur from tasks submitted to mpvGLQueue . Restricting all drawing to a single serial dispatch queue eliminates the data race with these two properties.
2 tasks
AnalysisThis issue is focused on access to these two private var needsMPVRender = false
private var forceRender = falseThese properties are used by the
The method Calling the FixingThe proposed fix in the PR restricts all drawing to a single serial dispatch queue, |
1 task
2 tasks
uiryuu
pushed a commit
that referenced
this issue
Oct 25, 2022
This commit will: - Change VideoLaye.draw to queue a task to the mpvGLQueue queue - Change MPVController.mpvUpdateCallback to call draw directly - Change MainWindowController.enterInteractiveMode to call draw directly - Change mpvGLQueue to be a private constant These changes cause all drawing to occur from tasks submitted to mpvGLQueue . Restricting all drawing to a single serial dispatch queue eliminates the data race with these two properties.
CarterLi
pushed a commit
to CarterLi/iina
that referenced
this issue
Jan 14, 2023
This commit will: - Change VideoLaye.draw to queue a task to the mpvGLQueue queue - Change MPVController.mpvUpdateCallback to call draw directly - Change MainWindowController.enterInteractiveMode to call draw directly - Change mpvGLQueue to be a private constant These changes cause all drawing to occur from tasks submitted to mpvGLQueue . Restricting all drawing to a single serial dispatch queue eliminates the data race with these two properties.
low-batt
added a commit
that referenced
this issue
Mar 5, 2023
This commit will: - Effectively revert the changes made in commit f8811b6 that attempted to always draw using the mpvGLQueue queue - Add an Atomic property wrapper to protect a property with a lock - Add locking to the VideoLayer properties blocked, forceRender and needsMPVRender The commit f8811b6 attempted to standardize drawing to always use the mpvGLQueue queue to resolve TSan detected data races reported in issue #3827 without using locks. However as discussed in issue #4055 drawing can still occur on the main thread. This commit resolves the TSan data races using locks.
2 tasks
MikeWang000000
pushed a commit
to MikeWang000000/iina
that referenced
this issue
Mar 8, 2023
This commit will: - Effectively revert the changes made in commit f8811b6 that attempted to always draw using the mpvGLQueue queue - Add an Atomic property wrapper to protect a property with a lock - Add locking to the VideoLayer properties blocked, forceRender and needsMPVRender The commit f8811b6 attempted to standardize drawing to always use the mpvGLQueue queue to resolve TSan detected data races reported in issue iina#3827 without using locks. However as discussed in issue iina#4055 drawing can still occur on the main thread. This commit resolves the TSan data races using locks.
svobs
pushed a commit
to svobs/iina-advance
that referenced
this issue
Mar 13, 2023
This commit will: - Effectively revert the changes made in commit f8811b6 that attempted to always draw using the mpvGLQueue queue - Add an Atomic property wrapper to protect a property with a lock - Add locking to the VideoLayer properties blocked, forceRender and needsMPVRender The commit f8811b6 attempted to standardize drawing to always use the mpvGLQueue queue to resolve TSan detected data races reported in issue iina#3827 without using locks. However as discussed in issue iina#4055 drawing can still occur on the main thread. This commit resolves the TSan data races using locks.
uiryuu
pushed a commit
that referenced
this issue
Mar 25, 2023
This commit will: - Effectively revert the changes made in commit f8811b6 that attempted to always draw using the mpvGLQueue queue - Add an Atomic property wrapper to protect a property with a lock - Add locking to the VideoLayer properties blocked, forceRender and needsMPVRender The commit f8811b6 attempted to standardize drawing to always use the mpvGLQueue queue to resolve TSan detected data races reported in issue #3827 without using locks. However as discussed in issue #4055 drawing can still occur on the main thread. This commit resolves the TSan data races using locks.
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System and IINA version:
Expected behavior:
IINA runs without error under Xcode with the thread sanitizer enabled.
Actual behavior:
Running under Xcode 13.4 on a M1 MacBookPro18,2 the thread sanitizer reports a data race:
Multiple threads are accessing this
ViewLayerproperty:Xcode console:
Steps to reproduce:
This is failing in IINA code.
How often does this happen?
Rarely.
The text was updated successfully, but these errors were encountered: