-
-
Notifications
You must be signed in to change notification settings - Fork 933
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
Thread deadlock in 9.83 #417
Comments
This is possibly fixed in v9.91. See dd12e89 Please re-open if it is not with updated ThreadSanitizer's output. Please update to latest version. |
Re-opening as i found an issue with this in the fix |
@aparajita do you have time to look in to this? NOTE: Please use develop branch and use |
@mkhan3189 Without looking deeply at the code, I wonder if you might be a recursive lock on the mutex within the same thread, in which case you need to use a recursive mutex. |
This fixes a thread deadlock that could occur in some situations, especially when running under Valgrind. See this issue on the easyloggingpp repo: abumq/easyloggingpp#417
Encfs recently changed to use easylogging++, and a thread deadlock has been reported in the logging library: vgough/encfs#244
The referenced issue has the relevant stack traces from ThreadSanitizer. Can you confirm that this is an issue w/ easylogging++?
WARNING: ThreadSanitizer: lock-order-inversion (potential deadlock) (pid=3933)
Cycle in lock order graph: M11 (0x7d480000be90) => M13 (0x7d4400009d90) => M17 (0x7d580000fc10) => M11
The text was updated successfully, but these errors were encountered: