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

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().

> 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.

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.)

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