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
asynPortDriver: data race on mutex in destructor #83
Comments
Would it work to take the lock in the destructor, wait to get it, release it, and then exit? |
Nope, that wouldn't work - for two reasons:
I noticed that |
mark0n
added a commit
to mark0n/asyn
that referenced
this issue
Apr 12, 2019
This prevents a potentially locked mutex from being destroyed as well as use-after-free bugs on other members of asynPortDriver. This fixes issue epics-modules#83.
mark0n
added a commit
to mark0n/asyn
that referenced
this issue
Apr 12, 2019
This prevents a potentially locked mutex from being destroyed as well as use-after-free bugs on other members of asynPortDriver. This fixes issue epics-modules#83.
Fixed via #84 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Every once in a while thread sanitizer reports a data race when running the unit tests for one of our drivers:
~asynPortDriver()
destroys the mutex but I don't see how we can be sure that the mutex is unlocked at this time. I'm wondering if the "asynPortDriverCallback" thread could still be holding the lock.The text was updated successfully, but these errors were encountered: