It's possible to lose data piped through standard output and/or error
streams when large ammounts of data are transfered.

Reproduction:
1) Process A spawns process B with all standard I/O pipes and transfers
large ammount of data to it (100kB in my sample).
2) Process B exits very early (doesn't process all stdin data) and puts
large amount of data into its stderr or stdout streams.
3) IOError/OSError exception if errno variable set to errno.EPIPE is
raised on process A side.

Bug:
When the exception is catched Popen object's stdout and stderr members
may not contain data put into stderr/stdout streams by process B.

Note:
Described behaviour can be observed in Python 2.6.1 on FreeBSD 7.2 as
well as on Windows XP (Pro x64, SP2, up to date).

Real life example of such early end of process B:
openssl smime -verify -CApath /some/dir with large, unsigned email.

I attach simple reproduction code (execute sender.py script).

Testing on Debian with latest trunk:
- the proposed example code works very well (I get all data).
- I added "subprocess._has_poll = False", and some (sometimes all) data
is lost. It seems that select() will return stdin even if it is not
writable.

On Windows of course, communicate() uses a blocking write, and always fail.

The proposed patch ignore the errors when EPIPE is raised, and simply
stops writing.

Your patch works for me with one exception:

On FreeBSD (python 2.6.1) OSError exception is raised by os.write
instead of IOError exception (raised by self.stdin.write on Windows).
The error code is same on both platforms.

Right, file.write raises IOError when os.write raises OSError :-(
Updated the patch.

Bump. Updated the patch against trunk.

I've updated the sample code to run with Python 3 and tested on Ubuntu 9.10 with and without setting subprocess._has_poll = False.

As expected, when using poll() the sample runs correctly.
When not using poll() the sample breaks (sometimes no data, sometimes some data; oddly, it seems the 'some data' variant appears only when I strace the process, probably because it slows things down).

I suggest this be committed against 3.2 as well, but I don't know how these things are usually done; should I produce a separate patch which ports the latest patch currently posted in this thead against py3k? Or will this be done by whomever applies the patch?

Closing as duplicate of #10963. See #10963 for more discussion.