Bug 93763 – WTF::monotonicallyIncreasingTime() compiled wrong by GCC 4.2

• Component: Web Template Framework
• Status: RESOLVED FIXED

[Tobias Netzel]

Created attachment 157863 [details]
better(?) implementation of WTF::monotonicallyIncreasingTime()

The current implementation of monotonicallyIncreasingTime() doesn't return the desired results, at least when compiled with GCC 4.2 on Mac OS X 10.5 PowerPC. While the result is indeed a monotonically increasing value of seconds, it overflows at a value of approx. 1001.xxxxxx, continuing with 0. This is probably caused by the double conversions done (or rather NOT done) in the right places. Maybe clang compiles this different than GCC or the current implementation works correctly on 64 bit (integer) platforms only or it's because of the 32 bit PowerPC having a 64 bit FPU; I didn't examine the assembly output.

The implementation in the attached patch is borrowed from libauto (http://www.opensource.apple.com/source/libauto/libauto-141.2/auto_zone.cpp) and returns the iMO correct value.

I stumbled over this problem with the current implementation because occasionally WebCore::ThreadTimers::sharedTimerFiredInternal() got stuck in an infinite loop when fireTime and timeToQuit had both values close to 1001.xxxxxx . While with the implementation from the patch this problems seems to be gone, it is probably still there but much much less probable to occur. What I want to say is that WebCore::ThreadTimers::sharedTimerFiredInternal() MUST be made overflow safe.

[Tobias Netzel]

Thinking it over maybe monotonicallyIncreasingTime() should indicate whether a overflow happened, i.e like this (just an idea):

double monotonicallyIncreasingTime(bool *overflow)
{
    static double previousTime = std::numeric_limits<float>::quiet_NaN();
    double result = 0.0;
    if (previousTime != previousTime) {
        previousTime = monotonicallyIncreasingTime();
    }
    result = monotonicallyIncreasingTime();
    if (overflow)
        *overflow = (result < previousTime)
    return result;
}

That way any places that need to know when an overflow has just happened can use monotonicallyIncreasingTime(bool *), for example WebCore::ThreadTimers::sharedTimerFiredInternal().

On the other hand, will the OS ever be running that much time (is it even possible?) for the timer to overflow?

[Tobias Netzel]

This was caused by mach_timebase_info.numer and mach_timebase_info.denom having integer type on OS X 10.5. Casting those to doubles solves the issue.