There appears to be a problem with a recent change made to test_subprocess to try and speed it up a bit. The commit with a problem seems to be 834650d63130 by Ross Lagerwall on 12 Feb 2012, and the problem is in test_poll(), which now looks like this:

    def test_poll(self):
        p = subprocess.Popen([sys.executable, "-c",
                              "import os",
                              "os.read(1)"], stdin=subprocess.PIPE)
        self.addCleanup(p.stdin.close)
        self.assertIsNone(p.poll())
        os.write(p.stdin.fileno(), b'A')
        p.wait()
        # Subsequent invocations should just return the returncode
        self.assertEqual(p.poll(), 0)

A number of problems here: -c only takes one parameter, so for example

./python -c "import os" "os.read(1)"

never does anything with the "os.read(1)". Possibly

"import os; os.read(1)"

was meant, but that doesn't work either: os.read takes two parameters, fd and n, so it seems that what is wanted is

"import os; os.read(0, 1)"

which appears to fulfill the intent to read a byte from stdin.

Because the command being run is effectively

python -c "import os"

the spawned command returns immediately. This (it would appear) leads to a race between the test process and the spawned process, such that sometimes the poll() returns None and sometimes it returns 0, due to the vagaries of the exact circumstances when the test is run. So the test passes on some machines but not on others.

It looks like it would be good to change the Popen call to use "import os; os.read(0, 1)" as the "-c" parameter value.

This was hopefully fixed in e5a94b56d6bc.

Was it one of the buildbots that was failing?

> Was it one of the buildbots that was failing?

No, I was doing some testing with the pythonv branch and ran into this on a Mac running OS X 10.5.8 (Leopard).

I'll re-test and close the issue if all is well.

Cool, thanks for reporting and debugging the issue :-)