This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients eryksun, jkloth, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2016-03-29.21:43:09
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1459287790.25.0.173240613838.issue26624@psf.upfronthosting.co.za>
In-reply-to
Content
> The deadlock is between a CRT thread initialization lock and Windows's process-wide module initialization lock. So if anything is being loaded on demand by the watchdog thread, it's probably locked too (and that could be within the CRT or the OS, so not easy to identify).

Basically, on timeout, the faulthandler thread uses the write() syscall and reads memory in the Python process. It's designed to be super safe. The code only uses async-signal safe functions, since the same code is used in signal handlers.

https://hg.python.org/cpython/file/688c6b16228e/Modules/faulthandler.c#l540

But the watchdog is trigerred by PyThread_acquire_lock_timed() which indirectly calls WaitForSingleObjectEx() on Windows. In expect that the wait times out before the lock is released on this buildbot.

Maybe Windows provides a safer function to implement a watchdog? Basically, the required function is a wait that can be interrupted.
History
Date User Action Args
2016-03-29 21:43:10vstinnersetrecipients: + vstinner, paul.moore, tim.golden, jkloth, zach.ware, eryksun, steve.dower
2016-03-29 21:43:10vstinnersetmessageid: <1459287790.25.0.173240613838.issue26624@psf.upfronthosting.co.za>
2016-03-29 21:43:10vstinnerlinkissue26624 messages
2016-03-29 21:43:09vstinnercreate