Intermittent timerfd failure on Android

[mhsmith]

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:

• https://buildbot.python.org/#/builders/1594/builds/54
• https://buildbot.python.org/#/builders/1594/builds/141

======================================================================
FAIL: test_timerfd_poll (test.test_os.TimerfdTests.test_timerfd_poll)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/user/0/org.python.testbed/files/python/lib/python3.14/test/test_os.py", line 4390, in test_timerfd_poll
    self.check_timerfd_poll(False)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File "/data/user/0/org.python.testbed/files/python/lib/python3.14/test/test_os.py", line 4378, in check_timerfd_poll
    self.assertEqual(self.read_count_signaled(fd), 1)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 2 != 1

----------------------------------------------------------------------
Ran 367 tests in 12.334s

FAILED (failures=1, skipped=120)
test test_os failed

Linked PRs

• gh-124873: Tolerate 100 ms in TimerfdTests on Android #127101
• [3.13] gh-124873: Tolerate 100 ms in TimerfdTests on Android (GH-127101) #127105
• gh-124873: Skip timerfd tests on Android #127279
• [3.13] gh-124873: Skip timerfd tests on Android (GH-127279) #127290

[mhsmith]

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]

Maybe CLOCK_RES_PLACES = 2 can be replaced with CLOCK_RES_PLACES = 1 to 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

[vstinner]

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.