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.

Sign up for GitHub

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

Jump to bottom

Potential data race on acceccing m_direntLookup #945

Closed
mgautierfr opened this issue Jan 16, 2025 · 0 comments
Closed

Potential data race on acceccing m_direntLookup #945

mgautierfr opened this issue Jan 16, 2025 · 0 comments

Comments

@mgautierfr
Copy link
Collaborator

Investigating cache configuration, it seems that we have a potential data race about accessing/initializing m_direntLookup.

This data race is in FileImpl::direntLookup() method : https://github.com/openzim/libzim/blob/main/src/fileimpl.cpp#L277-L293

The field m_direntLookup (std::unique_ptr) is accessed from different threads and std::unique_ptr is not thread safe. (https://learn.microsoft.com/en-us/cpp/standard-library/thread-safety-in-the-cpp-standard-library?view=msvc-170)
The lock we have only avoid us to create the dirent lookup twice but it doesn't prevent us to read and write m_direntLookup in the same time.
mgautierfr added a commit that referenced this issue Feb 7, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
433e1b4 
Reading and writing in the same time to a unique_ptr is not thread safe.
So the first read in `getDirent` (not lock protected) is a potential
race condition as we can also write to it (lock protected).

This is sad but we have to always get a lock to get the direntLookup.

Fix #945
mgautierfr added a commit that referenced this issue Feb 7, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
6c5f25e 
Reading and writing in the same time to a unique_ptr is not thread safe.
So the first read in `getDirent` (not lock protected) is a potential
race condition as we can also write to it (lock protected).

This is sad but we have to always get a lock to get the direntLookup.

Fix #945
mgautierfr added a commit that referenced this issue Feb 10, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
0593f17 
Reading and writing in the same time to a unique_ptr is not thread safe.
So the first read in `getDirent` (not lock protected) is a potential
race condition as we can also write to it (lock protected).

This is sad but we have to always get a lock to get the direntLookup.

Fix #945
mgautierfr added a commit that referenced this issue Feb 12, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
5a4fd26 
Reading and writing in the same time to a unique_ptr is not thread safe.
We introduce a atomicBool to know if the unique_ptr has been initialized.

Fix #945
mgautierfr added a commit that referenced this issue Feb 12, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
83883ff 
Reading and writing in the same time to a unique_ptr is not thread safe.
We introduce a atomicBool to know if the unique_ptr has been initialized.

Fix #945
mgautierfr added a commit that referenced this issue Feb 12, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
d770348 
Reading and writing in the same time to a unique_ptr is not thread safe.
We introduce a atomicBool to know if the unique_ptr has been initialized.

Fix #945
mgautierfr added a commit that referenced this issue Feb 17, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
91afabf 
Reading and writing in the same time to a unique_ptr is not thread safe.
We introduce a atomicBool to know if the unique_ptr has been initialized.

Fix #945
mgautierfr added a commit that referenced this issue Feb 17, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
fa21419 
Reading and writing in the same time to a unique_ptr is not thread safe.
We introduce a atomicBool to know if the unique_ptr has been initialized.

Fix #945
mgautierfr added a commit that referenced this issue Feb 26, 2025
@mgautierfr
Fix potential race condition on m_direntLookup initialization.
34ed246 
Reading and writing in the same time to a unique_ptr is not thread safe.
We introduce a atomicBool to know if the unique_ptr has been initialized.

Fix #945
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mgautierfr