Fix sem_clockwait detection for cross-compiled builds#985
Open
andiradulescu wants to merge 3 commits intoastral-sh:mainfrom
Open
Fix sem_clockwait detection for cross-compiled builds#985andiradulescu wants to merge 3 commits intoastral-sh:mainfrom
andiradulescu wants to merge 3 commits intoastral-sh:mainfrom
Conversation
When cross-compiling against old glibc headers (e.g., Debian Stretch's glibc 2.24), configure cannot detect sem_clockwait (added in glibc 2.30). This causes CPython to fall back to sem_timedwait with CLOCK_REALTIME, making threading.Event.wait() hang indefinitely when the system clock jumps backward (e.g., NTP sync). Add patches that declare sem_clockwait as a weak symbol on Linux when configure didn't detect it. At runtime, the weak symbol resolves to the real function on glibc 2.30+ or to NULL on older glibc. The patched code checks this at runtime and falls back to sem_timedwait gracefully. Version-specific patches for CPython 3.10, 3.11, 3.12, and 3.13+ account for differences in the threading internals across versions.
Contributor
|
Looks like the patch needs to be modified to apply cleanly on 3.15 (currently in alpha). |
andiradulescu
force-pushed
the
fix-sem-clockwait-weak-symbol
branch
from
a688da3 to
8ac6af1
Compare
In 3.15, the semaphore lock code moved from thread_pthread.h to parking_lot.c.
andiradulescu
force-pushed
the
fix-sem-clockwait-weak-symbol
branch
from
8ac6af1 to
4f545d7
Compare
Author
|
Added the 3.15 patch. The 3.15 one is simpler than the others. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When cross-compiling against old glibc headers (e.g., Debian Stretch's
glibc 2.24), configure cannot detectsem_clockwait(added in glibc 2.30). This causes CPython to fall back tosem_timedwaitwith CLOCK_REALTIME, makingthreading.Event.wait()hang indefinitely when the system clock jumps backward (e.g., NTP sync).This PR adds patches that declare
sem_clockwaitas a weak symbol on Linux when configure doesn't detect it. At runtime, the weak symbol resolves to the real function onglibc 2.30+or to NULL on older glibc. The patched code checks this at runtime and falls back tosem_timedwaitgracefully.Version-specific patches for CPython 3.10, 3.11, 3.12, 3.13+ (including 3.14) and 3.15 (currently in alpha) account for differences in the threading internals across versions.
The issue was first discovered in commaai/openpilot#33993 (comment)
Test results
All patches verified by building on Debian Stretch (glibc 2.24, where
sem_clockwaitdoesn't exist in headers) and running on Debian Bookworm (glibc 2.36):Event.wait(0.1)sem_timedwaitfallbacktest-sem-clockwait.py