Author db3l
Recipients Johan Dahlin, db3l, emilyemorehouse, eric.snow, nascheme, ncoghlan, pmpp, serhiy.storchaka, vstinner, yselivanov
Date 2019-04-13.02:02:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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 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\", 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\", line 4157, in test_daemon_threads_shutdown_stdout_deadlock
  File "D:\cygwin\home\db3l\python.test\lib\test\", 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.
Date User Action Args
2019-04-13 02:02:22db3lsetrecipients: + db3l, nascheme, ncoghlan, vstinner, pmpp, eric.snow, serhiy.storchaka, yselivanov, emilyemorehouse, Johan Dahlin
2019-04-13 02:02:22db3lsetmessageid: <>
2019-04-13 02:02:22db3llinkissue33608 messages
2019-04-13 02:02:22db3lcreate