[Django] #26011: allow_reuse_address = 1 on WSGIServer can cause random test failures in LiveServerTestCase on Windows
Django
LiveServerTestCase on Windows
-----------------------------------+--------------------
Reporter: knbk | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------------+--------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26011>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_docs: => 0
* needs_better_patch: => 0
* needs_tests: => 0
* stage: Unreviewed => Accepted
Comment:
Thanks for investigating that. Unfortunately, I can't advise on the proper
solution.
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:1>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Type: Bug | Status: assigned
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by knbk):
* owner: nobody => knbk
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:2>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Type: Bug | Status: assigned
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by knbk):
* has_patch: 0 => 1
Comment:
PR: https://github.com/django/django/pull/5895
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:3>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"c87540cee5a3d5b676b9359c01bdea35f733aabb" c87540ce]:
{{{
#!CommitTicketReference repository=""
revision="c87540cee5a3d5b676b9359c01bdea35f733aabb"
Fixed #26011 -- Prevented random LiveServerTestCase test failures on
Windows.
Prevented LiveServerTestCase from stealing ports used by concurrent
processes on Windows.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:4>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: closed => new
* has_patch: 1 => 0
* resolution: fixed =>
Comment:
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'
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:5>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by knbk):
* has_patch: 0 => 1
Comment:
New PR: https://github.com/django/django/pull/5918
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:6>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"b551eda9c5670e70b8f4bc7569e46fc617d87ff8" b551eda]:
{{{
#!CommitTicketReference repository=""
revision="b551eda9c5670e70b8f4bc7569e46fc617d87ff8"
Refs #26011 -- Fixed AttributeError in test_port_bind test.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:7>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Component: Testing framework | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by knbk):
* status: new => closed
* resolution: => fixed
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:8>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Type: Bug | Status: closed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
Could [http://djangoci.com/job/master-%E1%BC%A5o%E1%BC%A5ascii-
path/database=mysql,label=trusty,python=python3.5/338/ these Jenkins
failures] be related?
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:9>
Django
LiveServerTestCase on Windows
Reporter: knbk | Owner: knbk
Type: Bug | Status: closed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by knbk):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26011#comment:10>