[Webkit-unassigned] [Bug 157924] REGRESSION (r188642): All pages are blank when printing a webpage in iOS Safari

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=157924

--- Comment #6 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to comment #5)
> (In reply to comment #4)
> > There are two issues I think:
> > 
> > 1) The functional style would have you let WTF::Condition do the time math
> > for you.  Instead of having a wait loop, do:
> > 
> > m_condition.waitFor(m_lock, timeout, [&] () -> bool { loop body });
> 
> Unfortunately this would just move the overflow into
> Condition::absoluteFromRelative(), where have these two lines:
> 
>     Clock::duration myRelativeTimeout =
>         std::chrono::duration_cast<Clock::duration>(relativeTimeout);
> 
>     return Clock::now() + myRelativeTimeout;
> 
> libc++ represents both nanoseconds and milliseconds using the same type
> (long long), so the duration_cast will overflow trying to convert the
> largest long long into an even larger number of nanosecond ticks. Now we're
> right back where we started, subtracting from Clock::now() instead of adding.

Can you file a bug about that? :-)

> 
> > 
> > 2) The style that I've been settling on is to just use doubles for time. 
> > Maybe when I have time to mess around I'll propose that we do this.  I've
> > encountered so many bugs due to std::chrono having overflows where our old
> > double-based time code would have recovered like a champ.  In fact, one of
> > those overflows was in GCC's version of libstdc++!  It would cause some uses
> > of std::condition_variable to freak out on Linux but not anywhere else.
> > 
> > In this case, we could just go back to using a double timeout. 
> > waitForSeconds(+Inf) should correctly cause our code to recognize that you
> > want to timeout forever.
> > 
> > I'm also fine with Geoff's proposed solution.
> 
> Yeah, this is basically what I proposed doing in Radar, although now Geoff
> made me realize that my patch has a totally unnecessary subtraction in it!
> 
> Thanks for the feedback, Geoff and Phil.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160519/27b226f3/attachment.html>