New submission from STINNER Victor <vstin...@redhat.com>:

I don't recall this failure previously, it looks like a regression.

https://buildbot.python.org/all/#/builders/58/builds/2001

======================================================================
FAIL: test_daemon_threads_shutdown_stdout_deadlock (test.test_io.CMiscIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_io.py", 
line 4138, in test_daemon_threads_shutdown_stdout_deadlock
    self.check_daemon_threads_shutdown_deadlock('stdout')
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_io.py", 
line 4129, in check_daemon_threads_shutdown_deadlock
    self.assertIn("Fatal Python error: could not acquire lock "
AssertionError: "Fatal Python error: could not acquire lock for 
<_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to 
daemon threads" not found in ''

--

Copy of David Bolen's (the buildbot worker owner) message on bpo-33608, 
msg336897:

"""
I suspect changes for this issue may be creating test_io failures on my windows 
builders, most notably my x86 Windows 7 builder where test_io has been failing 
both attempts on almost all builds.  It fails with a lock failure during 
interpreter shutdown, and commit ef4ac967 appears the most plausible commit out 
of the set introduced at the first failing build on Feb 24.

See https://buildbot.python.org/all/#/builders/58/builds/1977 for the first 
failure.  test_io has failed both attempts on all but 3 of the subsequent 16 
tests of the 3.x branch.

It might be worth noting that this builder is slow, so if there are timeouts 
involved or a race condition of any sort it might be triggering it more readily 
than other builders.  I do, however, see the same failures - albeit less 
frequently and not usually on both tries - on the Win8 and Win10 builders.

For what it's worth one other oddity is that while having test_multiprocessing* 
failures are relatively common on the Win7 builder during the first round of 
tests due to exceeding the timeout, they usually pass on the retry, but over 
this same time frame have begun failing - not due to timeout - even on the 
second attempt, which is unusual.  It might be coincidental but similar 
failures are also showing up sporadically on the Win8/Win10 builders where such 
failures are not common at all.
"""

----------
components: Tests
messages: 337073
nosy: db3l, eric.snow, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_io: test_daemon_threads_shutdown_stdout_deadlock() fails on x86 
Windows7 3.x
versions: Python 3.8

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to