Title: test_xmlrpc is still flakey
Type: Stage:
Components: Versions: Python 3.0, Python 2.6
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: alanmcintyre, georg.brandl, nnorwitz, schmir
Priority: normal Keywords:

Created on 2007-11-27 01:23 by gvanrossum, last changed 2010-10-13 00:09 by schmir. This issue is now closed.

Messages (14)
msg57864 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-11-27 01:23
See e.g.:

Note how it fails the first time and passes on the re-run.  I've seen
this before (just not on any of my own systems).  I've also seen it fail
twice (on buildbot machines).
msg64566 - (view) Author: Ralf Schmitt (schmir) Date: 2008-03-26 21:25
The current buildbot has errors similar to this one (I assume):

Exception happened during processing of request from ('', 53126)
Traceback (most recent call last):
  File "/Users/ralf/trunk/Lib/", line 281, in
    self.process_request(request, client_address)
  File "/Users/ralf/trunk/Lib/", line 307, in process_request
    self.finish_request(request, client_address)
  File "/Users/ralf/trunk/Lib/", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/Users/ralf/trunk/Lib/", line 615, in __init__
  File "/Users/ralf/trunk/Lib/", line 318, in handle
  File "/Users/ralf/trunk/Lib/", line 301, in
    self.raw_requestline = self.rfile.readline()
  File "/Users/ralf/trunk/Lib/", line 369, in readline
    data = self._sock.recv(self._rbufsize)
error: [Errno 35] Resource temporarily unavailable


The problem is that the test calls

in the http_server function. This implicitly sets the server socket to
nonblocking state.
The accept call then returns a socket object, which
- is blocking on OS X 10.4 ppc
- is nonblocking on linux

I can easily reproduce that on my mac mini g4 with python 2.6.
msg64567 - (view) Author: Ralf Schmitt (schmir) Date: 2008-03-26 22:01
I just double checked with the following program:
#! /usr/bin/env python

import os
import fcntl
import socket

def isnonblocking(fd):
    return bool(fcntl.fcntl(fd, fcntl.F_GETFL, 0) & os.O_NONBLOCK)

def main():
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    s.bind(("", 8000))

    print "server isnonblocking:", isnonblocking(s.fileno())
    client, addr = s.accept()
    print "client isnonblocking:", isnonblocking(client.fileno())
if __name__=="__main__":

on my g4 mac it prints:
~/ python                                                 
ralf@mini ok
server isnonblocking: True
client isnonblocking: True

on linux:
~/ python mini/                                           
ralf@rat64 ok
server isnonblocking: True
client isnonblocking: False
msg64568 - (view) Author: Ralf Schmitt (schmir) Date: 2008-03-26 22:08
now that I see that the buildbot was running on ppc *Debian* I'm not
quite sure if we're talking about the same issue.
msg64569 - (view) Author: Alan McIntyre (alanmcintyre) * (Python committer) Date: 2008-03-26 22:10
It's my fault the xmlrpc tests try to use non-blocking sockets.  That
got added because sometimes failing tests would just sit there with the
server blocking until the entire test process got killed for running too

There are some tests that are skipped in test_xmlrpc because of
(apparent) Windows socket quirks; should they also be skipped for OS X
PPC, or should the flaky tests just be scrapped?

When I was last working on this I couldn't come up with a better way to
run these tests, so unless somebody can suggest a new approach I'm just
left with recommending the skip & scrap options as the only way to stop
the flakiness.
msg64570 - (view) Author: Ralf Schmitt (schmir) Date: 2008-03-26 22:18
No, please do not disable them. I'm not quite sure what to do, but
apparently these sockets returned from accept should be turned into
blocking sockets.
I just do not know, where this should happen. I think that this could
even be done inside the accept call (which then might break some code).
At least it should be done in the BaseHTTPServer code, which apparently
cannot handle nonblocking sockets.
msg64571 - (view) Author: Ralf Schmitt (schmir) Date: 2008-03-26 22:54
With the following diff, passes without problems.

Like I said, someone else should decide where to turn on blocking mode.
I now think that it should be in the socket.accept (i.e. in the C code)
at least for unix platforms.
Those who really want a nonblocking socket, will most probably call that
setblocking(0) anyway (or their program is broken on linux, which
returns blocking sockets by default).

--- a/Lib/	Wed Mar 26 22:41:36 2008 +0100
+++ b/Lib/	Wed Mar 26 23:48:13 2008 +0100
@@ -441,8 +441,10 @@
         May be overridden.
-        return self.socket.accept()
+        r= self.socket.accept()
+        r[0].setblocking(1)
+        return r
     def close_request(self, request):
         """Called to clean up an individual request."""
msg64616 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2008-03-28 06:39
Ugh.  The manpage for accept on Ubuntu 6.10 says:

On  Linux,  the  new  socket returned by accept() does not inherit file
status flags such as O_NONBLOCK and O_ASYNC from the listening  socket.
This  behaviour  differs from the canonical BSD sockets implementation.
Portable programs should not rely on inheritance or non-inheritance  of
file  status  flags and always explicitly set all required flags on the
socket returned from accept().
""" says that Windows
(CE, but I assume all variants) are like BSD in that they inherit

"""The newly created socket is the socket that will handle the actual
connection and has the same properties as socket s, including the
asynchronous events registered with the WSAEventSelect function."""

I assume that means blocking behavior.

I checked in r61993 which should fix the immediate problem with
test_xmlrpc.  I wonder if we should change socket to do the same thing
for all platforms.
msg69720 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-07-15 21:26
Does anybody still care about this?
msg69724 - (view) Author: Ralf Schmitt (schmir) Date: 2008-07-15 22:25
I still think that blocking mode should be turned on in socket.accept.
settimeout implicitly sets non-blocking mode (which might be a bit
The sockets returned from accept() being in non-blocking mode is
surprising (as this bug shows).
msg70750 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-08-05 16:09
Without a patch this will not improve.
msg70759 - (view) Author: Ralf Schmitt (schmir) Date: 2008-08-05 19:34
I would say without a decision on what to do, there will be no patch :)

I can write a patch, which unconditionally turns on blocking mode for
sockets returned from accept (on unix-platforms). Would that be fine?
msg114599 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2010-08-21 23:06
I've not seen special failures of test_xmlrpc lately.
msg118490 - (view) Author: Ralf Schmitt (schmir) Date: 2010-10-13 00:09
The tests now pass, but the underlying issue hasn't been fixed!
Date User Action Args
2010-10-13 00:09:22schmirsetmessages: + msg118490
2010-08-22 01:21:28gvanrossumsetnosy: - gvanrossum
2010-08-21 23:06:44georg.brandlsetstatus: open -> closed

nosy: + georg.brandl
messages: + msg114599

resolution: out of date
2008-08-05 19:34:57schmirsetmessages: + msg70759
2008-08-05 16:09:20gvanrossumsetmessages: + msg70750
2008-07-15 22:25:04schmirsetmessages: + msg69724
2008-07-15 21:26:44gvanrossumsetmessages: + msg69720
2008-03-28 06:39:54nnorwitzsetnosy: + nnorwitz
messages: + msg64616
2008-03-26 22:54:23schmirsetmessages: + msg64571
2008-03-26 22:18:16schmirsetmessages: + msg64570
2008-03-26 22:10:06alanmcintyresetnosy: + alanmcintyre
messages: + msg64569
2008-03-26 22:08:43schmirsetmessages: + msg64568
2008-03-26 22:01:32schmirsetmessages: + msg64567
2008-03-26 21:25:11schmirsetnosy: + schmir
messages: + msg64566
versions: + Python 2.6
2007-11-27 01:23:19gvanrossumcreate