David Oxley <pyt...@psi.epsilon.org.uk> added the comment: Another instance of a blocking function within subprocess not being protected against EINTR
Python 2.6.4, subprocess.py, Popen function, line 1115: data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB If a signal arrives while blocked in this read, the EINTR/OSError is passed up to whatever called subprocess.Popen. Retrying the Popen doesn't help because the child process may already have started but the caller has no way to know this nor does the caller have any control over the child process. === In the example code, the first subprocess.Popen starts without issue but while in the second Popen call, p1's SIGCHLD is received by the parent. p2 is never set, but the second copy of /bin/date starts running anyway. The "preexec_fn = lambda : time.sleep(2)" in the second Popen is a little contrived but serves to guarantee that the SIGCHLD will break the Popen for the purposes of the demonstration. I have seen this failure mode when using vanilla Popen calls although you have to be lucky/unlucky to see it. ==== This is in python 2.6.4: > md5sum subprocess.py 2ac8cefe8301eadce87630b230d6fff2 subprocess.py ==== I expect the fix is equivalent to cmiller's trunk-diff-unified.txt ---------- nosy: +mathmodave Added file: http://bugs.python.org/file15869/bugtest.py _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1068268> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
