-
Notifications
You must be signed in to change notification settings - Fork 165
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
Fix data races in VersionManager #6411
Conversation
4b23725
to
29f1bf1
Compare
CHANGELOG.md
Outdated
@@ -6,6 +6,7 @@ | |||
|
|||
### Fixed | |||
* `SyncSession::pause()` could hold a reference to the database open after shutting down the sync session, preventing users from being able to delete the realm. ([#6372](https://github.com/realm/realm-core/issues/6372), since v13.3.0) | |||
* Fix a data race in `DB::VersionManager`. If one thread committed a write transaction which increased the number of live versions above the previous highest seen during the current session at the same time as another thread began a read, the reading thread could read from a no-longer-valid memory mapping ([PR #6411](https://github.com/realm/realm-core/pull/6411), since v13.0.0). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How could end users experience this? @tgoyne could this be rephrased in end user terms that could easily be put in the SDK release notes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a data race detected by tsan, not something we observed functional problems from. I have no idea what would happen when the race is hit other than that it'd be bad.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to know, then maybe we should add. "This hasn't been reported by any users" or similar?
29f1bf1
to
39056a5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Access to `m_info` was not guarded by a lock, so one thread could potentially remap it while another thread was reading from it.
39056a5
to
d36645e
Compare
Access to
m_info
was not guarded by a lock, so one thread could potentially remap it while another thread was reading from it. TSan sometimes catches this running the Swift tests.