Even though same code works fine under Python 2.7(r27:82500, Aug 07 2010, 16:54:59) and Python 2.6.6 (r266:84292, Jun 12 2011, 20:37:17), I get following error using multiprocessing.reduction module no matter what I try. Complete code example that gives this error is also attached.

Traceback (most recent call last):
File "/usr/lib/python2.7/multiprocessing/reduction.py", line 127, in _serve
send_handle(conn, handle_wanted, destination_pid)
File "/usr/lib/python2.7/multiprocessing/reduction.py", line 80, in send_handle
_multiprocessing.sendfd(conn.fileno(), handle)
OSError: [Errno 9] Bad file descriptor

I forgot to mention that I use

Python 2.7.2 (default, Nov 21 2011, 17:24:32) 
[GCC 4.6.2] on linux2

Linux yasar-laptop 3.1.4-1-ARCH #1 SMP PREEMPT Tue Nov 29 09:08:04 UTC 2011 i686 Intel(R) Pentium(R) M processor 1.86GHz GenuineIntel GNU/Linux

Two patches have recently modified this part of the code:
http://hg.python.org/cpython/rev/d4d9a3e71897
http://hg.python.org/cpython/rev/cd15473a9de2

I'm unable to reproduce the problem on Linux 3.1.0 x86 with branch 2.7 (for those who would like to try, you just need to connect to port 9090/tcp, e.g. with netcat). Also, none of the buildbots complains, so this is rather surprising.

Yaşar, could you test to find out which patch introduced the problem ?
Also, could you provide the result of:
$ strace -f -e network,dup,dup2,close ./python ~/multiprocesssockserv.py

when you run your test?

Do you get the error upon the first connection?

I would love to test which patch introduced the problem, but I am not sure how should I do that. (Get the python source, change it and recompile?). I am also adding output of strace here.

Ok, I figured how to test for those patches. I just tested my code against those versions, and suprisingly I didn't get any errors. I am adding output of three different versions now. Each filename corresponds to regarded version.

Looking at the strace output:
Successful test:
sendmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"\267", 1}], msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, 0) = 1

The FD sent is 7 ({7} field), which makes sense.

Unsuccessful test:
sendmsg(11, {msg_name(0)=NULL, msg_iov(1)=[{"\0", 1}], msg_controllen=16, {cmsg_len=16, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, {263}}, msg_flags=0}, 0) = -1 EBADF (Bad file descriptor)

See the FD sent is 263?
263 == 0x107, which means that the lower bit of the second byte corresponding the FD hasn't been set: this is exactly the bug fixed by 
http://hg.python.org/cpython/rev/d4d9a3e71897 (see http://bugs.python.org/msg142627).
So this should definitely be fixed in current 2.7.

If you confirm it is fixed, then we can close this bug report.

Now, you might wonder why this worked with 2.6.6 and 2.7.
I think it's mere luck: if we're lucky and CMSG_DATA(cmsg) refers to a memory location which happens to be zero-filled, it'll work. If not, it'll break.

Appereantly my distribution's build used this http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tar.xz, and that version was bugged. But I tried building this http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2 and that build worked successfully. I am just asking this to be sure: latter is supposed to be latest version of 2.7, right? If so, I can confirm this bug is fixed on the latest 2.7.

> But I tried building this
> http://www.python.org/ftp/python/2.7/Python-2.7.tar.bz2 and that
> build worked successfully.

This is 2.7, which is more than a year old.
The most recent 2.7 version is http://www.python.org/ftp/python/2.7.2/Python-2.7.2.tar.bz2
However, the two patches above have been committed after this release, so I'd like to make sure that this works with the current 2.7 branch.
You can get it from there:
http://hg.python.org/cpython/archive/2.7.tar.bz2 (or with mercurial).

Current 2.7 branch is ok. This bug report can be closed.

Alright, thanks!