[Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point<steady_clock>

aaron at aarongraham dot com gcc-bugzilla@gcc.gnu.org
Sat May 9 21:29:00 GMT 2015


Aaron Graham <aaron at aarongraham dot com> changed:

           What    |Removed                     |Added
                 CC|                            |aaron at aarongraham dot com

--- Comment #3 from Aaron Graham <aaron at aarongraham dot com> ---
This is still a problem in current gcc trunk.

The bug is in the condition_variable::wait_until clock conversion. It doesn't
check for overflow in that math. Since the steady_clock and system_clock epochs
can be very different, it's likely to overflow with values much less than

    template<typename _Clock, typename _Duration>
      wait_until(unique_lock<mutex>& __lock,
                 const chrono::time_point<_Clock, _Duration>& __atime)
        // DR 887 - Sync unknown clock to known clock.
        const typename _Clock::time_point __c_entry = _Clock::now();
        const __clock_t::time_point __s_entry = __clock_t::now();
        const auto __delta = __atime - __c_entry;
        const auto __s_atime = __s_entry + __delta;

        return __wait_until_impl(__lock, __s_atime);

I modified my version of gcc to use steady_clock as condition_variable's "known
clock" (__clock_t). This is more correct according to the C++ standard and most
importantly it makes condition_variable resilient to clock changes when used in
conjunction with steady_clock. Because of this, in my case, it works fine with
steady_clock::time_point::max(), but fails with

Because I made that change and since I don't do timed waits on system_clock
(which is unsafe), the overflow hasn't been a problem for me and I haven't
fixed it.

More information about the Gcc-bugs mailing list