GeezerVison

All commit authors signed the Contributor License Agreement.

Thank you for your interest in contributing to Python. This is a community-driven project, and we want it to be a welcoming place to learn and collaborate.

Contributors are responsible for reviewing and understanding what they submit, checking its claims, and being able to explain changes in their own words. This helps reviewers focus on the contribution and leaves more time to support other contributors.

This contribution appears to have been authored with AI assistance. Please explain your contribution in your own words and describe how you checked its correctness.

Please read our guidelines for using AI tools.

I can only reproduce this on musl; elsewhere the new test passes without the fix. Please explain why and make sure your changes are minimal and focused.

AI-assisted technical explanation, posted at the author's request.

musl’s blocking semaphore path can return success while leaving errno set to EAGAIN: sem_trywait sets it when empty, and sem_timedwait, also used by sem_wait, can subsequently succeed without restoring the incoming value. A separate valid POSIX semaphore example returned 0 with errno 11 on musl 1.2.6; the identical program returned 0 with errno 0 on glibc. This is an observed libc difference, not a claim that glibc must always preserve errno.

In CPython, reattachment can park during GC and reach _PySemaphore_Wait. os.listdir checks errno after Py_END_ALLOW_THREADS, so reattachment can turn a successful readdir EOF into a spurious error. Debug builds already save/restore errno here; the native fix remains just the removal of four conditional-compilation lines.

The regression is now a 16-line method in aac344d, using four ordinary threads, GC, os.listdir, and the existing run_concurrently helper. The identical reduced test genuinely failed with errno 11 before and passed after the unchanged fix on both main and 3.15 native release free-threaded musl builds, once per phase, with mapped-library hashes checked. The full test_os module then passed both tests on each corrected runtime. This also explains why a passing pre-fix run on another libc does not rule out the bug.