You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was able to reproduce this by doing something else on the emulator while running the test repeatedly in -F mode – starting Chrome was usually enough. My initial understanding of the test was that the process would need to be suspended for at least 1/8 of a second for it to fail this way, but surely if that was happening, lots of other time-sensitive tests would fail as well. More detailed investigation is needed.
If this is caused by the emulator suspending the tests to run some higher-priority task, we might be able to increase the priority of the tests by making them start a visible activity.
Since this is a Linux-only feature exposed via a BSD-based libc, it’s also possible Android's implementation is buggy, or at least different enough that it breaks assumptions in the test.
For now I'll disable the test to avoid the buildbots posting useless messages on GitHub. It would be no great loss to disable the entire timerfd feature on Android, since it's a Linux-only feature which isn't widely used. But since it's already been released as part of 3.13, that would technically be a breaking change rather than a bug fix.
Maybe CLOCK_RES_PLACES = 2 can be replaced with CLOCK_RES_PLACES = 1 to tolerate 100 ms difference on Android? See test_os.py:
classTimerfdTests(unittest.TestCase):
# 1 ms accuracy is reliably achievable on every platform except Android# emulators, where we allow 10 ms (gh-108277).ifsys.platform=="android"andplatform.android_ver().is_emulator:
CLOCK_RES_PLACES=2else:
CLOCK_RES_PLACES=3
Sorry for the slow reply. Unfortunately this won't fix the failure, because it's happening at a point in the test earlier than any of the CLOCK_RES variables are involved.
This issue hasn't caused any full buildbot failures since #127101 was merged, but there have been failures which passed on a rerun and are therefore reported as warnings:
Activity
mhsmith commentedon Nov 20, 2024
I was able to reproduce this by doing something else on the emulator while running the test repeatedly in -F mode – starting Chrome was usually enough. My initial understanding of the test was that the process would need to be suspended for at least 1/8 of a second for it to fail this way, but surely if that was happening, lots of other time-sensitive tests would fail as well. More detailed investigation is needed.
If this is caused by the emulator suspending the tests to run some higher-priority task, we might be able to increase the priority of the tests by making them start a visible activity.
Since this is a Linux-only feature exposed via a BSD-based libc, it’s also possible Android's implementation is buggy, or at least different enough that it breaks assumptions in the test.
For now I'll disable the test to avoid the buildbots posting useless messages on GitHub. It would be no great loss to disable the entire timerfd feature on Android, since it's a Linux-only feature which isn't widely used. But since it's already been released as part of 3.13, that would technically be a breaking change rather than a bug fix.
vstinner commentedon Nov 21, 2024
Maybe
CLOCK_RES_PLACES = 2can be replaced withCLOCK_RES_PLACES = 1to tolerate 100 ms difference on Android? See test_os.py:pythongh-124873: Tolerate 100 ms in TimerfdTests on Android
gh-124873: Tolerate 100 ms in TimerfdTests on Android (#127101)
pythongh-124873: Tolerate 100 ms in TimerfdTests on Android (pythonGH…
vstinner commentedon Nov 21, 2024
I made the change bab4b04 since tests failed recently: #126730 (comment). Let's see how it goes with 100 ms instead of 10 ms.
[3.13] gh-124873: Tolerate 100 ms in TimerfdTests on Android (GH-127101…
Revert "[3.13] pythongh-124873: Tolerate 100 ms in TimerfdTests on An…
mhsmith commentedon Nov 26, 2024
Sorry for the slow reply. Unfortunately this won't fix the failure, because it's happening at a point in the test earlier than any of the CLOCK_RES variables are involved.
This issue hasn't caused any full buildbot failures since #127101 was merged, but there have been failures which passed on a rerun and are therefore reported as warnings:
test_timerfd_ns_polltest_timerfd_ns_selectandtest_timerfd_pollSo I've created #127279 to revert #127101 and skip these tests until we have time to investigate this further.
gh-124873: Skip timerfd tests on Android (#127279)
pythongh-124873: Skip timerfd tests on Android (pythonGH-127279)
vstinner commentedon Nov 26, 2024
The test is now skipped on Android: 4ca2c82.
[3.13] gh-124873: Skip timerfd tests on Android (GH-127279) (#127290)
mhsmith commentedon Dec 13, 2024
Similar report on Gentoo: #126112.
pythongh-124873: Tolerate 100 ms in TimerfdTests on Android (python#1…
pythongh-124873: Skip timerfd tests on Android (python#127279)