test_multiprocessing is giving multiple errors like
Process Process-21:
Traceback (most recent call last):
  File "F:\Python\dev\py27\lib\multiprocessing\process.py", line 258, in _bootstrap
    self.run()
  File "F:\Python\dev\py27\lib\multiprocessing\process.py", line 114, in run
    self._target(*self._args, **self._kwargs)
  File "F:\Python\dev\py27\lib\test\test_multiprocessing.py", line 1703, in _test
    conn.send('hello')
IOError: [Errno 10038] An operation was attempted on something that is not a socket
...
  File "F:\Python\dev\py27\lib\test\test_multiprocessing.py", line 1419, in _putter
    manager.connect()
  File "F:\Python\dev\py27\lib\multiprocessing\managers.py", line 500, in connect
    conn = Client(self._address, authkey=self._authkey)
  File "F:\Python\dev\py27\lib\multiprocessing\connection.py", line 465, in XmlClient
    return ConnectionWrapper(Client(*args, **kwds), _xml_dumps, _xml_loads)
  File "F:\Python\dev\py27\lib\multiprocessing\connection.py", line 175, in Client
    answer_challenge(c, authkey)
  File "F:\Python\dev\py27\lib\multiprocessing\connection.py", line 420, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
IOError: [Errno 10038] An operation was attempted on something that is not a socket

After a few of these, it hangs and I have to either kill multiple processes with TaskManager (or maybe kill-python would work) or kill the console. All tracebacks seem to one of these two. The common factor is 'not a socket'. It seems that something in the test should be skipped on windows. I got similar results running test_multiprocessing by itself. The process numbers are haphazard.

For 3.3 and 3.4, test went on for several minutes putting out [###### refs] lines but finally said '1 test OK'. I tried 3.2 again and it never outputs refs lines but fairly soon gives errors.

running kill-python results in
Warning -- threading._dangling was modified by test_multiprocessing
Warning -- multiprocessing.process._dangling was modified by test_multiprocessing
test test_multiprocessing failed -- multiple errors occurred; run in verbose mode for details

-v added the attached details, and the test finished, though failed.

Does this happen every time you run the tests?  (I don't see these errors.)

All 4 or 5 times I tried on 3.2, yes.

Could you try the following program:

import socket
import multiprocessing
import multiprocessing.reduction
import multiprocessing.connection

def socketpair():
    with socket.socket() as l:
        l.bind(('localhost', 0))
        l.listen(1)
        s = socket.socket()
        s.connect(l.getsockname())
        a, _ = l.accept()
        return s, a

def bar(s):
    print(s)
    s.sendall(b'from bar')

if __name__ == '__main__':
    a, b = socketpair()
    p = multiprocessing.Process(target=bar, args=(b,))
    p.start()
    b.close()
    print(a.recv(100))

In Command Prompt, 3.2 gave same error as before, 3.3 a different error.
multi-test.txt has full tracebacks.

Now could you try the attached file?  (It will not work on 2.7 because a missing socket.fromfd().)

P.S. It looks like the error for 3.3 is associated with a file f:\python\mypy\traceback.py which presumably clashes with the one in the standard library.

Both 3.2 and 3.3 give essentially the same traceback as 3.2 did before, both with installed python and yesterdays debug builds.

> Both 3.2 and 3.3 give essentially the same traceback as 3.2 did before, 
> both with installed python and yesterdays debug builds.

It looks like on your machine socket handles are not correctly inherited by child processes -- I had assumed that they always would be.

I suppose to fix things for 3.2 and earlier it would be necessary to backport the functionality of socket.socket.share() and socket.fromshare() from 3.3.

My original report was for 32 bit debug build on 64 bit Win 7 machine. I just re-ran test_multiprocessing with installed 64 bit python with same result. Was "I don't see these errors." on different Windows or non-Windows.

One option is to skip the failing sub-tests on Windows, like some other sub-tests:
skipped 'does not work with windows sockets'
and consider the limitation on use of multi-processing in 2.7,3.2 as "won't fix". (My view is that 3.2 users should upgrade as soon as dependencies allow.) Backporting new features requires pydev discussion.

> My original report was for 32 bit debug build on 64 bit Win 7 machine.
> I just re-ran test_multiprocessing with installed 64 bit python with same 
> result. Was "I don't see these errors." on different Windows or non-Windows.

On 64-bit Windows 7 with both 32 and 64 bit builds.

> One option is to skip the failing sub-tests on Windows, like some other sub-tests:
> skipped 'does not work with windows sockets'
> and consider the limitation on use of multi-processing in 2.7,3.2 as "won't fix". 
> (My view is that 3.2 users should upgrade as soon as dependencies allow.) 

Yes, I would be inclined to do that.

> Backporting new features requires pydev discussion.

I only meant exposing that functionality in the private _multiprocessing extension.

Same OS, different hardware, drivers, and buried settings, surprisingly different behavior. Oh, well. I will test any changes you decide on that need testing.

All 4 or 5 times I tried on 3.2, yes.
In Command Prompt, 3.2 gave same error as before, 3.3 a different error.
multi-test.txt has full tracebacks.'http://www.einstantloan.co.uk/'

This is no longer a 3.x issue. 3.2 and 3.3 get security fixes only. For 3.4, test_multiprocessing is split into 4 files and all run in multiple tries. Test_multiprocessing_spawn takes a minute, but it does 264 + 20 skipped tests, including a few 'wait' tests.

Three tries with 2.7 also passed.