New submission from And Clover <a...@doxdesk.com>:
Since bpo-15038, waiting to acquire locks/events/etc from _thread/threading on Windows can fail to return long past the requested timeout. Cause: https://github.com/python/cpython/blob/3.8/Python/thread_nt.h#L85 using 32-bit GetTickCount/DWORD, which will overflow at around 49.7 days of uptime. If the WaitForSingleObjectEx call in PyCOND_TIMEDWAIT returns later than the 'target' time, and the tick count overflows in that gap, 'milliseconds' will become very large (up to another 49.7 days) and the next PyCOND_TIMEDWAIT will be stuck for a long time. Where we've seen it is where it's most likely to happen: when the machine is hibernated during the WaitForSingleObjectEx call. I believe the TickCount continues to increase during hibernation so there is a much bigger gap between 'target' and 'now' for the overflow to happen in. Simplest fix is probably to switch to GetTickCount64/ULONGLONG. We should be able to get away with using this now we no longer support WinXP. ---------- components: Library (Lib), Windows messages: 363346 nosy: aclover, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: EnterNonRecursiveMutex on win32 can hang for 49.7 days type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39847> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
