New submission from Dave Malcolm <dmalc...@redhat.com>:

If we start a short-lived process which finishes before we begin communicating 
with it (e.g. by crashing), we can receive a SIGPIPE due to the receiving 
process no longer existing.  This becomes an EPIPE, which becomes an:
  OSError: [Errno 32] Broken pipe

Arguably this is a bug; if the subprocess could crash, the user currently has 
to check for it by both monitoring the returncode _and_ catching OSError (then 
examining for this specific errno), which seems ugly to me.

I'm attaching a patch for subprocess which handles this case, masking the 
OSError within the Popen implementation, so that you have to test for it within 
the returncode, in one place, rather than wrap every call with a try/except.

It could be argued that this is incorrect, as it masks under-reads of stdin by 
the subprocess.  However I believe a sanely-written subprocess ought to 
indicate success/failure back with its return code.

This was originally filed downstream within the Red Hat bugzilla instance as:
  https://bugzilla.redhat.com/show_bug.cgi?id=667431

The handler part of the patch is based on a patch attached there by Federico 
Simoncelli; I don't know if he has signed a PSF contributor agreement, however 
the size of the patch is sufficiently small that I suspect it's not 
copyrightable, and I've somewhat rewritten it since; I wrote the unit test.

----------
components: Library (Lib)
files: py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch
keywords: patch
messages: 126643
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: "subprocess" can raise OSError (EPIPE) when communicating with 
short-lived processes
versions: Python 3.3
Added file: 
http://bugs.python.org/file20469/py3k-handle-EPIPE-for-short-lived-subprocesses-2011-01-20-001.patch

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10963>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to