157937 2016-05-19 17:53:56 -0700 WTF::Condition::waitFor() will time out immediately for relativeTimeout values with very large tick counts 2016-11-03 12:32:32 -0700 1 1 1 Unclassified WebKit Web Template Framework WebKit Nightly Build All All RESOLVED DUPLICATE 152045 https://bugs.webkit.org/show_bug.cgi?id=157924 InRadar P2 Major --- 1 aestes webkit-unassigned aestes fpizlo ggaren webkit-bug-importer oldest_to_newest 1195060 0 aestes 2016-05-19 17:53:56 -0700 As discussed in <https://bugs.webkit.org/show_bug.cgi?id=157924>, WTF::Condition::waitFor() times out immediately if given a relativeTimeout of std::chrono::milliseconds::max(), due to two signed integer overflow bugs conspiring against us in Condition::absoluteFromRelative(). The first happens in this comparison: if (relativeTimeout > Clock::duration::max()) { std::chrono::duration converts the operands of its inequality operators to the type common to both durations (using std::common_type) before performing the comparison. In this case that's nanoseconds, and converting milliseconds::max() to nanoseconds will overflow since they both use the same underlying data type. The second happens on this line, for the same reason, except this time the conversion is explicit: Clock::duration myRelativeTimeout = std::chrono::duration_cast<Clock::duration>(relativeTimeout); Since the check that was supposed to protect us from overflowing itself overflowed, we now have a negative relative timeout. 1195061 1 webkit-bug-importer 2016-05-19 17:55:06 -0700 <rdar://problem/26382498> 1195400 2 fpizlo 2016-05-21 19:41:00 -0700 (In reply to comment #0) > As discussed in <https://bugs.webkit.org/show_bug.cgi?id=157924>, > WTF::Condition::waitFor() times out immediately if given a relativeTimeout > of std::chrono::milliseconds::max(), due to two signed integer overflow bugs > conspiring against us in Condition::absoluteFromRelative(). > > The first happens in this comparison: > > if (relativeTimeout > Clock::duration::max()) { > > std::chrono::duration converts the operands of its inequality operators to > the type common to both durations (using std::common_type) before performing > the comparison. In this case that's nanoseconds, and converting > milliseconds::max() to nanoseconds will overflow since they both use the > same underlying data type. Wow! I did not know about this behavior. That's so awkward! I don't think I would have been so enthusiastic about using std::chrono if I had known how overflow-prone it was. > > The second happens on this line, for the same reason, except this time the > conversion is explicit: > > Clock::duration myRelativeTimeout = > std::chrono::duration_cast<Clock::duration>(relativeTimeout); > > Since the check that was supposed to protect us from overflowing itself > overflowed, we now have a negative relative timeout. Dang, that's too funny. 1195456 3 ggaren 2016-05-22 18:20:07 -0700 Kind of sad that std::chrono devotes so much boilerplate to giving each time unit its own type, only to explode anyway due to overflow. :( 1195457 4 fpizlo 2016-05-22 18:40:26 -0700 (In reply to comment #3) > Kind of sad that std::chrono devotes so much boilerplate to giving each time > unit its own type, only to explode anyway due to overflow. :( Yes. I think we need to stop using std::chrono. I just sent a proposal to that effect to webkit-dev. 1247802 5 fpizlo 2016-11-03 12:32:32 -0700 *** This bug has been marked as a duplicate of bug 152045 ***