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
{{ message }}
Repository navigation
Occasional failure in installed 3.13.0 test_int #125076
On Windows, on tests of 1 and about 14 of 16, so maybe 1 in 10: same failure.
0:00:10 load avg: 11.46 [223/478/1] test_int failed (1 failure)
test test_int failed -- Traceback (most recent call last):
File "C:\Programs\Python313\Lib\test\test_int.py", line 738, in test_denial_of_service_prevented_str_to_int
self.assertLessEqual(sw_fail_extra_huge.seconds, sw_convert.seconds/2)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 0.015625 not less than or equal to 0.0078125
if it is only being flaky on a specific platform feel free to add a platform specific skip. we only need this to run in CI on at least one tier1 platform. 0.015625 not less than or equal to 0.0078125 suggests the timer resolution is 0.0078125 and thus it's easy to be skewed by interruptions or aliasing around timer tick boundaries. potentially more common on faster machines.
For background: since this test was added, converting to str was optimized so much that it takes less than a Windows clock tick. But, I haven't been able to reproduce this reliably outside buildbots.
@terryjreedy, do you see this on a machine where you could test a fix?
The failing line 738 is one you merged.
Yes, for #114911, I factored out similar logic from a couple of places in the tests. I didn't make the timeouts smaller. (Didn't mean to, anyway.)
That issue is still open. I'll close this as duplicate.
Activity
zware commentedon Oct 7, 2024
I've seen this now and then on buildbots. I believe it is Windows-specific and due to clock resolution.
terryjreedy commentedon Oct 7, 2024
If so, then the assertion value should be doubled on Windows.
terryjreedy commentedon Oct 7, 2024
@encukou The failing line 738 is one you merged.
gpshead commentedon Oct 8, 2024
if it is only being flaky on a specific platform feel free to add a platform specific skip. we only need this to run in CI on at least one tier1 platform.
0.015625 not less than or equal to 0.0078125suggests the timer resolution is 0.0078125 and thus it's easy to be skewed by interruptions or aliasing around timer tick boundaries. potentially more common on faster machines.gpshead commentedon Oct 8, 2024
(this skip is worth backporting to all branches that contain this test)
skirpichev commentedon Oct 8, 2024
(All supported branches have this test.)
encukou commentedon Oct 8, 2024
For background: since this test was added, converting to str was optimized so much that it takes less than a Windows clock tick. But, I haven't been able to reproduce this reliably outside buildbots.
@terryjreedy, do you see this on a machine where you could test a fix?
Yes, for #114911, I factored out similar logic from a couple of places in the tests. I didn't make the timeouts smaller. (Didn't mean to, anyway.)
That issue is still open. I'll close this as duplicate.