Comment 1 for bug 1752683
Revision history for this message
| Rafael David Tinoco (rafaeldtinoco) wrote | #1 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
7020100
(Get the code!)
I have found the cause of why the race condition happened and was able to verify that apache2 upstream version (ldap module) also suffers from the same issue. Instead of re-describing the problem here I'll give you the URLs of where I'm working upstream:
This bug was already opened in 2015:
https:/
And again in 2016:
https:/
My notes are here:
https:/
And actually the notes were the ones that helped me finding all the upstream bits for this particular bug. As you can see in apache upstream bug, an engineer from EA.COM proposed a small patch solving the external lock need that I also identified. He has also reported this in debian project:
https:/
I sent my findings upstream as a new comment to the existing bug in apache2 project because I wanted to check on what was going to be done by the maintainer, since there are multiple ways of solving this (internal and/or external lock), and I could help in any of them.
Maintainer responded:
https:/
Saying that he has already fixed this behaviour:
2 Changes with Apache 2.5.1
3
4 *) mod_ldap: Avoid possible crashes, hangs, and busy loops due to
5 improper merging of the cache lock in vhost config.
6 PR 43164 [Eric Covener]
by changing an external (to rmm allocator logic) lock that wasn't working. The lock was being copied in a callback after it was being used, causing the race condition because there was no external (to rmm) lock and rmm lock wasn't being used.