You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Traceback (most recent call last):
File "C:\projects\cpython\lib\test\test_asyncio\test_sslproto.py", line 284, in test_start_tls_server_1
asyncio.wait_for(main(), loop=self.loop, timeout=10))
File "C:\projects\cpython\lib\asyncio\base_events.py", line 440, in run_until_completereturn future.result()
File "C:\projects\cpython\lib\asyncio\tasks.py", line 398, in wait_forraise futures.TimeoutError()
concurrent.futures._base.TimeoutError
Traceback (most recent call last):
File "C:\projects\cpython\lib\test\test_asyncio\functional.py", line 43, in tearDownself.fail('unexpected calls to loop.call_exception_handler()')
AssertionError: unexpected calls to loop.call_exception_handler()
I'm leaving on a two-weeks vacation today. To avoid risking breaking the workflow, I'll mask this tests on AppVeyor. I'll investigate this when I get back.
After fresh update and debug rebuild on master(3.7), with Win10 patched last night, I got
======================================================================
FAIL: test_call_later (test.test_asyncio.test_events.ProactorEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "F:\dev\3x\lib\test\test_asyncio\test_events.py", line 290, in test_call_laterself.assertTrue(0.08<= t1-t0 <=0.8, t1-t0)
AssertionError: False is not true : 0.07800000000861473
I have not seen this before. Four subsequent runs passed.
It's a race condition which doesn't depend on the OS, but on the system load.
Yeah, I agree. The current timeout for the test is 5 seconds and it tries to transfer 2mb of data, which isn't that much actually. I'll bump the timeout and reduce the amount of data transferred in #7130
Thing is, these are the very first *functional* tests for asyncio. Before it was mostly tested with mocks. So we'll need some adjustment period to learn how slow/loaded the CI servers are and what kind of timeouts are safe to use.
Yeah, I agree. The current timeout for the test is 5 seconds and it tries to transfer 2mb of data, which isn't that much actually. I'll bump the timeout and reduce the amount of data transferred in #7130
What is the purpose of a timeout of 5 seconds? Some buildbots are really slow.
If the purpose is to detect when the test hangs: use a timeout of 5 minutes, or at least 1 minute (60 seconds).
While Yury seems unable to reproduce the bug, it's easy for me to reproduce it on Linux. After 2 hours of debugging, I found the root issue: a race condition not in the test, but in asyncio itself! => bpo-33674 "asyncio: race condition in SSLProtocol".
I'm not 100% sure that all issues are fixed, but the tests seem much more reliable yet. I close the issue. If the bug reoccurs, I will reopen the issue or open a new one.
Activity
pitrou commentedon Dec 30, 2017
It seems test_asyncio fails sporadically on AppVeyor:
https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.10081#L2650
======================================================================
ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLS)
----------------------------------------------------------------------
======================================================================
FAIL: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLS)
----------------------------------------------------------------------
1st1 commentedon Dec 30, 2017
I'm leaving on a two-weeks vacation today. To avoid risking breaking the workflow, I'll mask this tests on AppVeyor. I'll investigate this when I get back.
1st1 commentedon Dec 30, 2017
New changeset 0c36bed by Yury Selivanov in branch 'master':
bpo-32458: Temporarily mask start-tls proactor test on Windows (bpo-5054)
0c36bed
1st1 commentedon Dec 30, 2017
Please keep this issue open.
terryjreedy commentedon Jan 5, 2018
After fresh update and debug rebuild on master(3.7), with Win10 patched last night, I got
======================================================================
FAIL: test_call_later (test.test_asyncio.test_events.ProactorEventLoopTests)
----------------------------------------------------------------------
I have not seen this before. Four subsequent runs passed.
asvetlov commentedon Jan 22, 2018
Hmm, the scheduled call was executed sooner than expected.
Actually we had 0.1 sec delay, checked for at least 0.08 but actual call time was 0.078
BTW I recall an issue with Windows when call_later() was executed sooner already.
ned-deily commentedon Mar 9, 2018
Note, I think this failure is still happening occasionally on the windows7 buildbot; for example:
http://buildbot.python.org/all/#/builders/111/builds/68/steps/3/logs/stdio
http://buildbot.python.org/all/#/builders/111/builds/85/steps/3/logs/stdio
18 remaining items
vstinner commentedon May 28, 2018
I just reproduced the issue on Linux. Open 3 terminals and run the commands in parallel:
(1) ./python -m test test_asyncio -m test_start_tls_server_1 -F
(2) ./python -m test -j16 -r
(3) ./python -m test -j16 -r
It's a race condition which doesn't depend on the OS, but on the system load.
1st1 commentedon May 28, 2018
Yeah, I agree. The current timeout for the test is 5 seconds and it tries to transfer 2mb of data, which isn't that much actually. I'll bump the timeout and reduce the amount of data transferred in #7130
Thing is, these are the very first *functional* tests for asyncio. Before it was mostly tested with mocks. So we'll need some adjustment period to learn how slow/loaded the CI servers are and what kind of timeouts are safe to use.
vstinner commentedon May 28, 2018
What is the purpose of a timeout of 5 seconds? Some buildbots are really slow.
If the purpose is to detect when the test hangs: use a timeout of 5 minutes, or at least 1 minute (60 seconds).
1st1 commentedon May 28, 2018
OK, sounds good, will do that.
vstinner commentedon May 28, 2018
Race condition! I created #7157 to increase the timeout from 5 seconds to 60 seconds.
1st1 commentedon May 28, 2018
#7130 is in. It includes many tests for TLS tests as well as bugfixes to asyncio code. Hopefully this all will make tests more stable.
1st1 commentedon May 28, 2018
New changeset 8267ea2 by Yury Selivanov in branch 'master':
bpo-32458: Further tune start_tls tests (bpo-7166)
8267ea2
vstinner commentedon May 28, 2018
While Yury seems unable to reproduce the bug, it's easy for me to reproduce it on Linux. After 2 hours of debugging, I found the root issue: a race condition not in the test, but in asyncio itself! => bpo-33674 "asyncio: race condition in SSLProtocol".
miss-islington commentedon May 28, 2018
New changeset 4b82846 by Miss Islington (bot) in branch '3.7':
bpo-32458: Further tune start_tls tests (GH-7166)
4b82846
1st1 commentedon May 29, 2018
Should we close this issue now?
vstinner commentedon May 29, 2018
I'm not 100% sure that all issues are fixed, but the tests seem much more reliable yet. I close the issue. If the bug reoccurs, I will reopen the issue or open a new one.