Repository navigation
Intermittent timerfd failure on Android #124873
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Oct 1, 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.
Maybe
CLOCK_RES_PLACES = 2can be replaced withCLOCK_RES_PLACES = 1to tolerate 100 ms difference on Android? See test_os.py:class TimerfdTests(unittest.TestCase): # 1 ms accuracy is reliably achievable on every platform except Android # emulators, where we allow 10 ms (gh-108277). if sys.platform == "android" and platform.android_ver().is_emulator: CLOCK_RES_PLACES = 2 else: CLOCK_RES_PLACES = 3
Maybe CLOCK_RES_PLACES = 2 can be replaced with CLOCK_RES_PLACES = 1 to tolerate 100 ms difference on Android?
I made the change bab4b04 since tests failed recently: #126730 (comment). Let's see how it goes with 100 ms instead of 10 ms.
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:
- https://buildbot.python.org/#/builders/1590/builds/231 –
test_timerfd_ns_poll - https://buildbot.python.org/#/builders/1590/builds/235 –
test_timerfd_ns_selectandtest_timerfd_poll
So I've created #127279 to revert #127101 and skip these tests until we have time to investigate this further.
- https://buildbot.python.org/#/builders/1590/builds/231 –
- added a commit that references this issue
on Nov 26, 2024 The test is now skipped on Android: 4ca2c82.
Similar report on Gentoo: #126112.
Bug report
This happens quite often, but usually doesn't cause a buildbot failure because it passes on the second attempt. However, it's now double-failed twice:
Linked PRs