David Bolen <db3l....@gmail.com> added the comment:
Eric, I'm also seeing the same Win7 and Win10 worker failures with commit b75b1a350 as last time (test_multiprocessing_spawn on both, and test_io on Win7). For test_multiprocessing_spawn, it fails differently than Victor since no core file is generated, but I assume it's related in terms of child process termination. See for example https://buildbot.python.org/all/#/builders/3/builds/2390 for Win10, where test_mymanager_context fails with: ====================================================================== FAIL: test_mymanager_context (test.test_multiprocessing_spawn.WithManagerTestMyManager) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\buildarea\3.x.bolen-windows10\build\lib\test\_test_multiprocessing.py", line 2747, in test_mymanager_context self.assertIn(manager._process.exitcode, (0, -signal.SIGTERM)) AssertionError: 3221225477 not found in (0, -15) ---------------------------------------------------------------------- (3221225477 is C0000005 which I believe is an access violation) For some reason, the Windows 7 worker didn't get a test run while your commit was live, but I can reproduce the same error manually. For test_io, as before, its a shutdown lock failure: ====================================================================== FAIL: test_daemon_threads_shutdown_stdout_deadlock (test.test_io.CMiscIOTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\cygwin\home\db3l\python.test\lib\test\test_io.py", line 4157, in test_daemon_threads_shutdown_stdout_deadlock self.check_daemon_threads_shutdown_deadlock('stdout') File "D:\cygwin\home\db3l\python.test\lib\test\test_io.py", line 4148, 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 '' ---------------------------------------------------------------------- In manual attempts I have yet to be able to recreate the test_multiprocessing_spawn failure under Win10 but can usually manage a 25-50% failure rate under Win7 (which is much slower). The test_io failure on Win7 however, appears to be more easily reproducible. It's possible I/O is more critical than CPU, or perhaps its impact on latency; I seem to more easily exacerbate the test_multiprocessing_spawn failure rate by loading down the host disk than its CPU. I also noticed that the Win10 failure was when test_io and test_multiprocessing_spawn overlapped. While I'm guessing this should happen on any low powered Windows VM, if it would help, I could arrange remote access to the Win7 worker for you. Or just test a change on your behalf. In fairness, it's unlikely to be useful for any significant remote debugging but perhaps at least having somewhere you could test a change, even if just with print-based debugging, might help. And while it might be an independent issue, the test_io failure rate appears to occur more reliably than test_multiprocessing_spawn. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33608> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
