gh-153400: Use glibc functions instead of syscall() - #155518
Conversation
Use glibc functions instead of syscall(): pidfd_open(), pidfd_getfd() and pidfd_send_signal() (glibc 2.36), gettid() and getdents64() (glibc 2.30), and getrandom() (glibc 2.25).
vstinner
changed the title
Use unsigned int for os.getrandom() flags and signal.pidfd_send_signal() flags.
vstinner
added
the
🔨 test-with-buildbots
|
🤖 New build scheduled with the buildbot fleet by @vstinner for commit b6bbfd9 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F155518%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
bedevere-bot
removed
the
🔨 test-with-buildbots
It looks good, thank you! |
The "test" step failed with a timeout, not good. I'm not sure if it's related to the change or not. |
|
!buildbot AMD64 Android |
|
🤖 New build scheduled with the buildbot fleet by @mhsmith for commit b6bbfd9 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F155518%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
|
The buildbot stopped working about 24 hours ago, so it's not related to this change. Testing manually, it appeared to work on the first run within each Gradle daemon, but if I interrupted it and tried again, it hung while starting the emulator. Removing the emulator snapshot and allowing it to be recreated seems to have fixed the issue. |
|
No, apparently not, and it looks like this previously happened for a few runs in a row on August 5, then again on August 6. In each case, it was triggered by a run that was cancelled for some reason, such as a master shutdown. Subsequent runs then stop at the line I'll shut the buildbot down until I have a chance to look into this. Notes to self:
We still have x86_64 being tested by GitHub Actions, and aarch64 by the other buildbot, so it doesn't need to block this PR. |
|
I didn't try any of the ideas above, because although I reproduced the problem several times, I wasn't able to do it reliably, so I'd have no way of knowing whether anything worked. None of the following things were good enough:
Instead, since the problem involves the Gradle daemon getting into a broken state, I disabled persistent daemons by adding this line to the worker startup script: This should make each run more independent, as it is on GitHub Actions. It only costs about 20 seconds per run. |
There was a problem hiding this comment.
[post merge review] confirming that this is safe. glibc's struct dirent64 is as above and has 256 bytes of d_name space declared. I think the linux kernel itself uses a sizeless d_name[] to expect the caller to allocate extra. if that happened here we'd wind up with a tiny struct without necessarily room for a name and an error from the syscall, silently falling back to a slower or unsafe code path instead.
5 participants
Use glibc functions instead of syscall(): pidfd_open(), pidfd_getfd() and pidfd_send_signal() (glibc 2.36), gettid() and getdents64() (glibc 2.30), and getrandom() (glibc 2.25).
Use unsigned int for os.getrandom() flags and signal.pidfd_send_signal() flags.