classification
Title: test_create_server() of test_asyncio failure on "x86 Windows Server 2008 [SB] 3.x" buildbot
Type: Stage:
Components: Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: brian.curtin, gvanrossum, sbt, tim.golden, vstinner, yselivanov
Priority: normal Keywords:

Created on 2014-02-21 09:46 by vstinner, last changed 2014-03-13 09:53 by vstinner. This issue is now closed.

Messages (5)
msg211839 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-02-21 09:46
It looks like the overlapped AcceptEx() operation was cancelled by something. But when the test_asyncio was replayed in verbose mode, the test passed.

Is it possible that a local firewall or antivirus cancelled the operation? It would be surprising since the test passed at the second try.

Related discussion on Apache HTTPD mailing list:
" My guess... you have a package that installed a network service provider filter and that filter is somehow doing a close on the event handle in the overlapped structure."
http://marc.info/?l=apache-httpd-dev&m=105959505627302&w=2

---

AcceptEx() documentation:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737524%28v=vs.85%29.aspx

test_create_server (test.test_asyncio.test_events.ProactorEventLoopTests) ...

Future/Task exception was never retrieved
future: _OverlappedFuture<exception=OSError(22, 'The I/O operation has been aborted because of either a thread exit or an application request', None, 995, None)>
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\asyncio\windows_events.py", line 428, in _poll
    value = callback(transferred, key, ov)
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\asyncio\windows_events.py", line 253, in finish_accept
    ov.getresult()
OSError: [WinError 995] The I/O operation has been aborted because of either a thread exit or an application request

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202008%20%5BSB%5D%203.x/builds/2365/steps/test/logs/stdio

======================================================================
FAIL: test_create_server (test.test_asyncio.test_events.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\home\cpython\buildslave\x86\3.x.snakebite-win2k8r2sp1-x86\build\lib\test\test_asyncio\test_events.py", line 642, in test_create_server
    self.assertEqual('CONNECTED', proto.state)
AssertionError: 'CONNECTED' != 'INITIAL'
- CONNECTED
+ INITIAL

---

test_create_server (test.test_asyncio.test_events.SelectEventLoopTests) ... ok
test_create_server (test.test_asyncio.test_proactor_events.BaseProactorEventLoopTests) ... FAIL
... later ...
test_create_server (test.test_asyncio.test_events.SelectEventLoopTests) ... ok
test_create_server (test.test_asyncio.test_proactor_events.BaseProactorEventLoopTests) ... ok
msg211870 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2014-02-21 17:43
I suspect it's just a race in the test. This happened to me recently too when I ran the tests on my Windows 7 laptop, and upon the second try it passed, so I just figured it was a race. After all the test does use run_briefly(), which might as well be renamed run_with_race_condition().
msg211871 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-02-21 17:50
> After all the test does use run_briefly(), which might as well be renamed run_with_race_condition().

Oh, it means that the "Future/Task exception was never retrieved" is a just a consequence of the failed assertion.

IMO the run_briefly() should be avoided, whereas it is used in many places. For example, the protocol used in test_create_server() should provide a future to wait until the protocol is connected.
msg211872 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2014-02-21 18:07
Agreed. I suppose all tests currently using run_briefly() should be modified to use run_until() with a lambda and a timeout. The timeout must be (a) large enough to never fail on a buildbot, yet (b) small enough that when a test is actually failing we don't mistake it for hanging. So I really would like to see a different pattern introduced -- but I'm at a loss for how to do it elegantly. (Ditto with the terrible hack for simulated time -- see http://code.google.com/p/tulip/issues/detail?id=128.)
msg213376 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-03-13 09:53
The following change should fix this issue.

changeset:   89480:56c346e9ae4d
user:        Victor Stinner <victor.stinner@gmail.com>
date:        Thu Mar 06 01:00:36 2014 +0100
files:       Lib/asyncio/test_utils.py Lib/test/test_asyncio/test_events.py
description:
asyncio, Tulip issue 157: Improve test_events.py, avoid run_briefly() which is
not reliable
History
Date User Action Args
2014-03-13 09:53:06vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg213376
2014-02-21 18:07:27gvanrossumsetmessages: + msg211872
2014-02-21 17:50:26vstinnersetmessages: + msg211871
2014-02-21 17:43:06gvanrossumsetmessages: + msg211870
2014-02-21 09:46:41vstinnercreate