-
Notifications
You must be signed in to change notification settings - Fork 161
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
76 additions
and
82 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ace2b8f
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.
Hi,
I suspect that this shouldn't compile then. It is weir that no body has discover this bug yet. I hav eno access to Windows. Please could you provide a PR.
ace2b8f
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.
Hi,
I think this has very little probability to happen, so no one found this. But we use the condition variables very actively in our project (many and many of wait/notify calls per second). And this works fine in Boost 1.64 and stops work in 1.65. I already tried a fix (replaced operator -> with dot) in our environment and it compiles and works as expected.
entry is a local variable in bool do_wait(lock_type& lock,timeout abs_time) function. Early (in 1.64) its destructor called
And now (in 1.65) you first call
entry->remove_waiter();
what is equivalent to
entry.entry->remove_waiter();
and finally the destructor of entry additionally calls entry_manager::remove_waiter function
so remove_waiter function of entry_manager::entry member will be called twice and the first call will be without locking of internal_mutex.
ace2b8f
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.
You are right. Using the same name for the function was an source of errors.
Thanks for catching this.