#26011 closed Bug (fixed)
allow_reuse_address = 1 on WSGIServer can cause random test failures in LiveServerTestCase on Windows
Reported by: | Marten Kenbeek | Owned by: | Marten Kenbeek |
---|---|---|---|
Component: | Testing framework | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Windows happily allows a process to steal another process's address when SO_REUSEADDR
is set. This can cause requests to go to the wrong LiveServerThread
, and cause random test failures, such as http://djangoci.com/job/pull-requests-windows/886/. I can't reproduce this issue on Linux.
The solution is quite simply to set allow_reuse_address
to 0
on our WSGIServer
implementation. The question is whether we want to do that only when running a LiveServerTestCase
, or on the base WSGIServer
class to prevent address stealing for manage.py runserver
as well.
Change History (10)
comment:1 by , 9 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 9 years ago
Has patch: | unset |
---|---|
Resolution: | fixed |
Status: | closed → new |
Saw this error on Jenkins with Python 2:
Traceback (most recent call last): File "/home/jenkins/workspace/django-master-trusty/database/sqlite3/label/trusty/python/python2.7/tests/servers/tests.py", line 191, in test_port_bind if e.ernrno == errno.EADDRINUSE: AttributeError: 'error' object has no attribute 'ernrno'
comment:8 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:10 by , 9 years ago
I think this patch exposes an existing bug. The current code expects the error when a socket is in use to be an socket.error
instance, but apparently it raises an OSError
in some circumstances. According to the Py3 docs, an OSError
should automatically be "upgraded" to the appropriate error type, but that doesn't seem to happen here. For our case it should be sufficient to catch an OSError
as well (we still need to catch socket.error
on Py2), and check the error code. I'm not sure why the OSError
constructor does not return a socket.error
, this might be a bug in Python. I'll investigate this later.
Thanks for investigating that. Unfortunately, I can't advise on the proper solution.