Tests failing on riscv64 and ppc64el

[juliangilbey]

Things to check first

• I have searched the existing issues and didn't find my bug already reported there

• I have checked that my bug is still present in the latest release

AnyIO version

4.6.2

Python version

Python 3.12

What happened?

On Debian, we run the test suite on multiple archs as part of our CI process. Some tests failed on ppc64el and riscv64. This could be because these archs are slow, but there may be a different reason. Complete test logs are currently available (though I do not know how long they are kept); I include the relevant output here. The tests all succeeded on the other tested archs.

ppc64el

118s =================================== FAILURES ===================================
118s ___________ TestRunAsyncFromThread.test_run_sync_from_thread_pooling ___________
118s tests/test_from_thread.py:194: in test_run_sync_from_thread_pooling
118s     pytest.fail("Worker thread did not exit within 1 second")
118s E   Failed: Worker thread did not exit within 1 second
118s ____________ TestBlockingPortalProvider.test_single_thread[asyncio] ____________
118s tests/test_to_thread.py:317: in test_single_thread
118s     assert threading.active_count() == active_threads_before
118s E   assert 1 == 2
118s E    +  where 1 = <function active_count at 0x7fff8b47d440>()
118s E    +    where <function active_count at 0x7fff8b47d440> = threading.active_count
118s =========================== short test summary info ============================

[Edit: the test_single_thread[asyncio] test is flaky: it passes sometimes]

riscv64

275s =================================== FAILURES ===================================
275s _________________ test_keyboardinterrupt_during_test[asyncio] __________________
275s /usr/lib/python3.12/subprocess.py:1264: in wait
275s     return self._wait(timeout=timeout)
275s /usr/lib/python3.12/subprocess.py:2045: in _wait
275s     raise TimeoutExpired(self.args, timeout)
275s E   subprocess.TimeoutExpired: Command '('/usr/bin/python3', '-mpytest', '--basetemp=/tmp/pytest-of-debci/pytest-0/test_keyboardinterrupt_during_test0/runpytest-0', '-v', '-p', 'anyio', '-p', 'no:asyncio', '-p', 'no:trio')' timed out after 3 seconds
275s 
275s During handling of the above exception, another exception occurred:
275s /tmp/autopkgtest-lxc.7v6gak57/downtmp/build.LbO/src/tests/test_pytest_plugin.py:470: in test_keyboardinterrupt_during_test
275s     testdir.runpytest_subprocess(*pytest_args, timeout=3)
275s /usr/lib/python3/dist-packages/_pytest/legacypath.py:236: in runpytest_subprocess
275s     return self._pytester.runpytest_subprocess(*args, timeout=timeout)
275s E   _pytest.pytester.Pytester.TimeoutExpired: 3 second timeout expired running: ('/usr/bin/python3', '-mpytest', '--basetemp=/tmp/pytest-of-debci/pytest-0/test_keyboardinterrupt_during_test0/runpytest-0', '-v', '-p', 'anyio', '-p', 'no:asyncio', '-p', 'no:trio')
275s ----------------------------- Captured stdout call -----------------------------
275s running: /usr/bin/python3 -mpytest --basetemp=/tmp/pytest-of-debci/pytest-0/test_keyboardinterrupt_during_test0/runpytest-0 -v -p anyio -p no:asyncio -p no:trio
275s      in: /tmp/pytest-of-debci/pytest-0/test_keyboardinterrupt_during_test0
275s =========================== short test summary info ============================

How can we reproduce the bug?

I presume that running the test suite on these archs will produce the same results; I have retried these tests, and they seem to be consistent across runs.
In Debian version 4.6.2-2, I will exclude these tests on these archs, so the test suite should pass. But if there is a significant underlying cause, it would obviously be better to address that.

[agronholm]

I would need to be able to reproduce these failures on my end, either locally or on CI. All of these issues seem timing sensitive, so if you'd like to explore solutions on your end, you could try upping the timeout values on the affected tests and see what happens. If you can eliminate the failures that way, I'd be happy to accept a PR.

[juliangilbey]

Hi @agronholm! An update...

I've tested these in clean chroots (the CI system uses lxc, but I don't have access to this on the development machines).

The ppc64el failures are unreproducible in that environment, so it must be something about the different lxc environment that causes this problem.

The riscv64 failure still occurs in the chroot, but increasing the timeout - even to 10 seconds - doesn't help. But there are so many weirdnesses about riscv64 that I wouldn't be overly concerned.

I'll just skip these tests (at least for now).