[issue43784] [Windows] interpreter hangs indefinitely on subprocess.communicate during __del__ at script exit
New submission from Kevin M :
I've noticed an issue (or user error) in which Python a call that otherwise
usually works in the __del__ step of a class will freeze when the Python
interpreter is exiting.
I've attached sample code that I've ran against Python 3.9.1 on Windows 10.
The code below runs a process and communicates via the pipe.
class SubprocTest(object):
def run(self):
print("run")
proc_args = ["cmd.exe"]
self._process = subprocess.Popen(proc_args,
stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
def __del__(self):
print("__del__")
if self._process is not None:
self.terminate()
def terminate(self):
print("terminate")
self._process.communicate(input=b"exit\n", timeout=1)
print("kill")
self._process.kill()
self._process = None
if __name__ == "__main__":
s = SubprocTest()
s.run()
del s
print("s done")
t = SubprocTest()
t.run()
print("t done")
Current output:
run
__del__
terminate
kill
s done
run
t done
__del__
terminate
<<<<<< hangs indefinitely here, even though timeout=1
Expected output:
run
__del__
terminate
kill
s done
run
t done
__del__
terminate
kill
In normal circumstances, when you del the object and force a run of __del__(),
the process ends properly and the terminate() method completes.
When the Python interpreter exits, Python calls the __del__() method of the
class. In this case, the terminate() never completes and the script freezes
indefinitely on the communicate()
--
components: Library (Lib), Windows
files: win_subprocess_hang.py
messages: 390587
nosy: paul.moore, steve.dower, sylikc, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [Windows] interpreter hangs indefinitely on subprocess.communicate
during __del__ at script exit
versions: Python 3.9
Added file: https://bugs.python.org/file49947/win_subprocess_hang.py
___
Python tracker
<https://bugs.python.org/issue43784>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43784] starting a thread in __del__ hangs at interpreter shutdown
Kevin M added the comment: eryksun, wow, that's speedy analysis, but there might be more to it. I went and tested a bunch of test cases. my subrocess code doesn't seem to hang on Linux where the thread example code does? Linux - Python 3.6.8 - your threading example DOESN'T hang Linux - Python 3.6.8 - My subprocess code also DOESN'T hang Linux - Python 3.8.5 - thread example HANGs Linux - Python 3.8.5 - My subprocess code also DOESN'T hang Windows - Python 3.9.1 - thread example HANGs Windows - Python 3.9.1 - subprocess code HANGs -- ___ Python tracker <https://bugs.python.org/issue43784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3801] cgi.parse_qsl does not return list
New submission from Kevin M. Turner <[EMAIL PROTECTED]>: This is a regression from 2.5 that causes our test suite to fail in 2.6. Looks like a cut-and-paste bug. Patch attached. -- components: Library (Lib) files: cgi_parse_qsl.diff keywords: patch messages: 72755 nosy: acapnotic severity: normal status: open title: cgi.parse_qsl does not return list versions: Python 2.6 Added file: http://bugs.python.org/file11417/cgi_parse_qsl.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3801> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15128] inspect raises exception when frames are misleading about source line numbers
New submission from Kevin M. Turner : The attached example shows how inspect.findsource fails when given a stack frame that points to a non-existent source line, and how inspect.getframeinfo and getinnerframes do not handle that failure. On the one hand, yes, this code was asking for it by building such a broken frame. On the other hand, having code that examines tracebacks result in tracebacks of its own sucks a whole bunch. The inspect find&get source methods are documented as returning IOError if they cannot find the source, and the calling code handles that case, so that's probably what should happen here. (Actually, that seems straightforward enough, I can make a patch for that shortly.) This may help with issue #1628987 as well. -- components: Library (Lib) files: inspectLineNumber.py messages: 163355 nosy: acapnotic priority: normal severity: normal status: open title: inspect raises exception when frames are misleading about source line numbers versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file26073/inspectLineNumber.py ___ Python tracker <http://bugs.python.org/issue15128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15128] inspect raises exception when frames are misleading about source line numbers
Kevin M. Turner added the comment: patch attached (against python 2.7 tip) -- keywords: +patch Added file: http://bugs.python.org/file26077/15128-inspect-source-linenum.diff ___ Python tracker <http://bugs.python.org/issue15128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19352] unittest loader barfs on symlinks
Changes by Kevin M. Turner : -- nosy: +acapnotic ___ Python tracker <http://bugs.python.org/issue19352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
