Bug 244302
| Summary: | POSIX implementation of ThreadCondition::timedWait() degenerates to wait() beyond 2038 | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Olivier Crête <olivier.crete> |
| Component: | Platform | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
Olivier Crête
The POSIX timedWait() implementation is based on getting the current wait clock time, converting it to a double, then converting it back into a timespec. It assumes that the timespec.tv_sec" field is a int, so it checks if the value if ">INT_MAX" and then waits forever. If one sets the system clock beyond 2038, then it will block forever. I hit this bug inside WebCore::ThreadedScrollingTree::waitForRenderingUpdateCompletionOrTimeout() which gets call when receiving a mouse wheel event, but I'm sure one can hit it from other places too.
Luckily for us, the timespec.tv_sec is not an int, but it's a time_t, which, since POSIX 2001 (and C11), has been defined as a 64 bit int. So we can just use the right checks and then it works!
Proposed fix is: https://github.com/WebKit/WebKit/pull/3621
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Olivier Crête
Pull request: https://github.com/WebKit/WebKit/pull/3621
EWS
Committed 253858@main (f63657fbf8c1): <https://commits.webkit.org/253858@main>
Reviewed commits have been landed. Closing PR #3621 and removing active labels.
Radar WebKit Bug Importer
<rdar://problem/99221433>