Author chris.jerdonek
Recipients aeros, asvetlov, chris.jerdonek, njs, vstinner, yselivanov
Date 2020-05-12.02:45:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1589251547.75.0.945895669413.issue38323@roundup.psfhosted.org>
In-reply-to
Content
I was able to simplify the script a lot more and continue to reproduce the hang. It's attached as test-kill3.py (80 lines). It doesn't use subprocess_exec() or a watcher anymore -- just subprocess.Popen() followed by popen.kill(), and then awaiting on a future.

The right amount of time has to elapse between the popen.kill() and the await, so I introduced a random bit of variability in between. The right range / amount of time to put in between probably depends on the machine. (What you want is a narrow range right on the borderline, where sometimes the signal fires right before the await, and sometimes right after.) I also added a printf() statement at the beginning of signalmodule.c's trip_signal(), so I can see in the console whether the signal is firing before or after the await. In the timeout / hang case, the signal will be firing after. The hang is very infrequent with the script, though (less frequent than the original unittest). It can take multiple 1-minute runs.

It seems similar issues have happened a number of times in the past around the signal-handling code. See e.g. https://bugs.python.org/issue30038 and changes to the neighboring code since then.
History
Date User Action Args
2020-05-12 02:45:47chris.jerdoneksetrecipients: + chris.jerdonek, vstinner, njs, asvetlov, yselivanov, aeros
2020-05-12 02:45:47chris.jerdoneksetmessageid: <1589251547.75.0.945895669413.issue38323@roundup.psfhosted.org>
2020-05-12 02:45:47chris.jerdoneklinkissue38323 messages
2020-05-12 02:45:47chris.jerdonekcreate