Running tests in parallel on Windows quits too soon

[terryjreedy]

On my Win10 the test suite completes when run serially. But with main and 3.11, but not 3.10, it quits too soon with -j0. This has occured with both repository debug builds and installed 3.11.0b4. Failure is currently deterministic with variable details. Presence of -ugui or -uall has no apparent effect.

What happens is that roughly about 100 tests before the end, a 'regrtest worker thread' fails ('warning') with UnicodeDecodeError: 'utf-8' codec can't decode byte 0x91 in position <variable>: invalid start byte. The 14 worker processes are stopped and the usual summary is given, but with an additional list of ' tests omitted <list of test names'. The test is called a 'SUCCESS'. This is followed by a traceback for SystemExit(0), followed by 1 or more tracebacks for PermissionError because a temporary test file is supposedly used by another process.

Attaching a file with output starting with the initial warning fails. Will paste separately.

If this is not limited to my system, I think it should be a release blocker.

[terryjreedy]

Sample failure.

  -- running: test_asyncio (1 min 20 sec), test_distutils (1 min 2 sec),
  test_concurrent_futures (1 min 9 sec), test_multiprocessing_spawn (32.3 sec)
Warning -- regrtest worker thread failed: Traceback (most recent call last):
Warning --   File "C:\Programs\Python311\Lib\test\libregrtest\runtest_mp.py", line 305, in run
Warning --     mp_result = self._runtest(test_name)
Warning --                 ^^^^^^^^^^^^^^^^^^^^^^^^
Warning --   File "C:\Programs\Python311\Lib\test\libregrtest\runtest_mp.py", line 272, in _runtest
Warning --     stdout = stdout_fh.read().strip()
Warning --              ^^^^^^^^^^^^^^^^
Warning --   File "C:\Programs\Python311\Lib\tempfile.py", line 483, in func_wrapper
Warning --     return func(*args, **kwargs)
Warning --            ^^^^^^^^^^^^^^^^^^^^^
Warning --   File "<frozen codecs>", line 322, in decode
Warning -- UnicodeDecodeError: 'utf-8' codec can't decode byte 0x91 in position 1332: invalid start byte
Kill <TestWorkerProcess #1 running test=test_ssl pid=15188 time=10.9 sec>
Kill <TestWorkerProcess #2 running test=test_tomllib pid=11616 time=782 ms>
Kill <TestWorkerProcess #3 running test=test_socket pid=17624 time=11.5 sec>
Kill <TestWorkerProcess #4 running test=test_asyncio pid=3644 time=1 min 21 sec>
Kill <TestWorkerProcess #5 running test=test_tools pid=8556 time=422 ms>
Kill <TestWorkerProcess #7 running test=test_concurrent_futures pid=17068 time=1 min 10 sec>
Kill <TestWorkerProcess #8 running test=test_tk pid=18116 time=1.8 sec>
Kill <TestWorkerProcess #9 running test=test_tarfile pid=444 time=7.3 sec>
Kill <TestWorkerProcess #10 running test=test_trace pid=9376 time=297 ms>
Kill <TestWorkerProcess #11 running test=test_threading pid=11716 time=5.0 sec>
Kill <TestWorkerProcess #12 running test=test_multiprocessing_spawn pid=2664 time=32.6 sec>
Kill <TestWorkerProcess #13 running test=test_subprocess pid=14384 time=8.9 sec>
Kill <TestWorkerProcess #14 running test=test_telnetlib pid=11752 time=6.9 sec>

== Tests result: SUCCESS ==

79 tests omitted:
    test_asyncio test_concurrent_futures test_distutils
    test_multiprocessing_spawn test_socket test_ssl test_subprocess
    test_tarfile test_telnetlib test_threading test_tk test_tomllib
    test_tools test_trace test_traceback test_tracemalloc
    test_ttk_guionly test_ttk_textonly test_tuple test_turtle
    test_type_annotations test_type_cache test_type_comments
    test_typechecks test_typing test_ucn test_unary test_unicode
    test_unicode_file test_unicode_file_functions
    test_unicode_identifiers test_unicodedata test_univnewlines
    test_unpack test_unpack_ex test_unparse test_urllib test_urllib2
    test_urllib2_localnet test_urllib2net test_urllib_response
    test_urllibnet test_urlparse test_userdict test_userlist
    test_userstring test_utf8_mode test_utf8source test_uu test_uuid
    test_venv test_wait3 test_wait4 test_warnings test_wave
    test_weakref test_weakset test_webbrowser test_winconsoleio
    test_winreg test_winsound test_with test_wsgiref test_xdrlib
    test_xml_dom_minicompat test_xml_etree test_xml_etree_c
    test_xmlrpc test_xmlrpc_net test_xxlimited test_xxtestfuzz
    test_yield_from test_zipapp test_zipfile test_zipfile64
    test_zipimport test_zipimport_support test_zlib test_zoneinfo

326 tests OK.

31 tests skipped:
    test_asdl_parser test_check_c_globals test_clinic test_curses
    test_dbm_gnu test_dbm_ndbm test_devpoll test_epoll test_fcntl
    test_fork1 test_gdb test_grp test_ioctl test_kqueue
    test_multiprocessing_fork test_multiprocessing_forkserver test_nis
    test_openpty test_ossaudiodev test_pipes test_poll test_posix
    test_pty test_pwd test_readline test_resource test_smtpnet
    test_socketserver test_spwd test_syslog test_threadsignals

Total duration: 1 min 22 sec
Tests result: SUCCESS
Traceback (most recent call last):
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 478, in temp_dir
    yield path
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 531, in temp_cwd
    yield cwd_dir
  File "C:\Programs\Python311\Lib\test\libregrtest\main.py", line 701, in main
    self._main(tests, kwargs)
  File "C:\Programs\Python311\Lib\test\libregrtest\main.py", line 758, in _main
    sys.exit(0)
SystemExit: 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Programs\Python311\Lib\test\support\__init__.py", line 201, in _force_run
    return func(*args)
           ^^^^^^^^^^^
PermissionError: [WinError 32] The process cannot access the file because it is
 being used by another process:
 'C:\\Users\\Terry\\AppData\\Local\\Temp\\test_python_6764æ\\test_python_worker_17068æ'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Programs\Python311\Lib\test\__main__.py", line 2, in <module>
    main()
  File "C:\Programs\Python311\Lib\test\libregrtest\main.py", line 763, in main
    Regrtest().main(tests=tests, **kwargs)
  File "C:\Programs\Python311\Lib\test\libregrtest\main.py", line 695, in main
    with os_helper.temp_cwd(test_cwd, quiet=True):
  File "C:\Programs\Python311\Lib\contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 529, in temp_cwd
    with temp_dir(path=name, quiet=quiet) as temp_path:
  File "C:\Programs\Python311\Lib\contextlib.py", line 155, in __exit__
    self.gen.throw(typ, value, traceback)
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 483, in temp_dir
    rmtree(path)
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 440, in rmtree
    _rmtree(path)
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 383, in _rmtree
    _waitfor(_rmtree_inner, path, waitall=True)
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 328, in _waitfor
    func(pathname)
  File "C:\Programs\Python311\Lib\test\support\os_helper.py", line 380, in _rmtree_inner
    _force_run(fullname, os.rmdir, fullname)
  File "C:\Programs\Python311\Lib\test\support\__init__.py", line 212, in _force_run
    return func(*args)
           ^^^^^^^^^^^
PermissionError: [WinError 32] The process cannot access the file because it is
 being used by another process:
 'C:\\Users\\Terry\\AppData\\Local\\Temp\\test_python_6764æ\\test_python_worker_17068æ'

[neonene]

Probably cp1252 is used as system locale on your OS which emits an error message with non-ascii characters such as 0x91 (left single quotation). If so, switching to utf-8 locale is the easiest way to finish running tests after a few retries:

https://websiteforstudents.com/how-to-change-system-locale-in-windows-11/

Another workaround would be using 'wb+' mode in TestWorkerProcess._runtest() to account for non-utf8 text from subprocess:

cpython/Lib/test/libregrtest/runtest_mp.py

Lines 261 to 266 in 547f0bb

	def _runtest(self, test_name: str) -> MultiprocessResult:
	# gh-94026: Write stdout+stderr to a tempfile as workaround for
	# non-blocking pipes on Emscripten with NodeJS.
	with tempfile.TemporaryFile(
	'w+', encoding=sys.stdout.encoding
	) as stdout_fh:

I'm not sure the root cause of the race condition when running test_asyncio and test_concurrent_futures.

[neonene]

Maybe related: gh-91227

[neonene]

See also: gh-91323 (specific to 3.11 and main)

[terryjreedy]

Multiprocessing people: due to some regression in 3.11/2, parallel tests on ma updated by otherwise pretty stock American Win10 started failing 29 days ago. They still fail today with essentially the same traceback. I believe they ran not too many months before.

@pablogsal Today, sequential tests also fail by hanging for hours in test_winconsoleio, after taking 81 minutes to get that far
1:21:51 [415/435] test_winconsoleio. (The suite once ran in 18 minutes on my machine.) test_repl alone took 34 minutes.

EDIT: This is with plain python -m test (with -j0 added for parallel).
EDIT2: On rerun, sequential tests ran OK in 55 minutes with 40 skipped. Will rerun again to make sure.

[pablogsal]

@pablogsal Today, sequential tests also fail by hanging for hours in test_winconsoleio, after taking 81 minutes to get that far
1:21:51 [415/435] test_winconsoleio. (The suite once ran in 18 minutes on my machine.) test_repl alone took 34 minutes.
Unfortunately I don't have a windows machine :( Could you bisect to find the commit that introduced the multiprocessing regression? I don't think that area changed a lot during 3.11/3.12

[terryjreedy]

The second sequential run was again fine, so forget winconsoleio. (I have no idea why the first run could have gone so badly.) Do the tests run in parallel on your non-windows machine?
@zooba Can you try -j0 on your Windows machine to verify that this is not a local-only problem?

To me, the output pasted above reveals two bugs in the testing program.

1. The premature shutdown is called a success rather than a failure.
2. Exiting after (wrongly) reporting success results in more exceptions.

git bisect wants a command that returns a 0/non-0 exit code. Though it would not help here, due to the fake 'success', is there a way to run regrtest and suppress printing and get an exit code instead? I looked at the 'Special runs;' options can could not find anything.

I do not know git beyond the devguide chapter, so I would need some coaching even to find a good version for bisect (other than by manually downloading and re-installing earlier releases). What would be a good way to get an exit-code command/script?