Test_AIO_TCPSSL::test_remote_shutdown_receives_trailing_data gets stuck on aarch64-linux #412
Comments
This test case gets stuck on our aarch64 builder since the 0.15.0 upgrade, and so the package has not been in the cache for aarch64, since the job reliably timed out. The issue didn't get noticed earlier because the package does in fact build on some aarch64 machines, like my raspberry pi 4. Reported upstream at MagicStack/uvloop#412.
|
There's also this failure on aarch64-darwin (aka Apple Silicon): It doesn't happen 100% of the time. |
mweinelt
changed the title
|
@bobrik As your report references a different test, has a different exception and runs on a slightly different architecture, I think you a probably better of creating a separate issue. |
|
Got some time today to reformat my SD card and install Debian on my Raspberry Pi 400 (kernel |
|
No luck - all tests passed. And the stack info is not really telling a lot. I think it should be safe to disable in your case, as For |
|
Yeah, I think this might be a weird issue with the python and this specific CPU generation. We've disabled that test and the build worked from then on. I don't think it's worth it digging too deep here. |
test_shutdown_timeout_handler_not_set() might have a race between the SHUT_WR message and `eof` asyncio event. This fix changes to use the eof_received() callback triggered by SHUT_WR. Refs MagicStack#412 2nd issue.
test_shutdown_timeout_handler_not_set() might have a race between the SHUT_WR message and `eof` asyncio event. This fix changes to use the eof_received() callback triggered by SHUT_WR. Refs #412 2nd issue.
test_shutdown_timeout_handler_not_set() might have a race between the SHUT_WR message and `eof` asyncio event. This fix changes to use the eof_received() callback triggered by SHUT_WR. Refs #412 2nd issue.
This release adds Python 3.10 support, updates bundled libuv to 1.42.0 and fixes a handful of issues. Changes ======= * Python 3.10 support (#432) (by @elprans in 2519e2d for #432) * Bump vendored libuv to 1.42.0 (#433) (by @elprans in a62f781 for #433) * Use cibuildwheel to build wheels (#435) (by @elprans in 20febe0 for #435) * Add support for <timer handle>.when() (by Jens Jorgensen in 62b2af9) Fixes ===== * Fix ref issue when protocol is in Cython (by @fantix in 70cafc8 for #2222) * set python_requires (by @graingert in c808a66) * SSL: schedule first data after waiter wakeup (by @fantix in 2081db8) * Fix a possible race condition in sslproto test (by @fantix in b0526cd for #412) * Fix `call_soon_threadsafe` thread safety (by @fantix in 4b803b1)
PYTHONASYNCIODEBUGin env?: n/aWe have an issue since upgrading to 0.15.0 where our builds on aarch64 are timing out during the test suite, specifically during this test case:
The following changes were made in 0.15 that touched this test case. Could one of them be related?
Our builders wait for 120 minute, but the test suite is really stuck there. I cannot reproduce the issue on a Raspberry Pi 4 (Linux 5.11.14, Python 3.8.9), but it is perfectly reproducible on an APM X-Gene 2 (Linux 4.19.188, Python 3.8.9).
This is the call trace at the time when it is stuck. We don't have python support in gdb sadly, so this is as detailed as it gets right now
or more detailed from gdb:
The text was updated successfully, but these errors were encountered: