[Webkit-unassigned] [Bug 93763] New: WTF::monotonicallyIncreasingTime() compiled wrong by GCC 4.2
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sat Aug 11 02:48:17 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=93763
Summary: WTF::monotonicallyIncreasingTime() compiled wrong by
GCC 4.2
Product: WebKit
Version: 528+ (Nightly build)
Platform: Macintosh
OS/Version: Unspecified
Status: UNCONFIRMED
Severity: Critical
Priority: P2
Component: Web Template Framework
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: tobias.netzel at googlemail.com
Created an attachment (id=157863)
--> (https://bugs.webkit.org/attachment.cgi?id=157863&action=review)
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.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list