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
#130007 introduced a change to the handling of C stack limits. This change intermittently causes the test_sys.SysModuleTest.get_allocated_blocks() test to fail:
======================================================================
FAIL: test_getallocatedblocks (test.test_sys.SysModuleTest.test_getallocatedblocks)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/buildbot/Library/Developer/XCTestDevices/AFB8404B-0B3C-4CD4-862A-BBCE48F86959/data/Containers/Bundle/Application/91D9D3A2-F680-47B8-AC8F-A68603BDDACC/iOSTestbed.app/python/lib/python3.14/test/test_sys.py", line 1104, in test_getallocatedblocks
self.assertLess(a, sys.gettotalrefcount())
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 548518 not less than 476363
----------------------------------------------------------------------
The exact values vary, but they're usually within ~500 or so.
sys.gettotalrefcount() is the total refcount per interpreter, but sys.getallocatedblocks() seems to be the total number of allocated blocks per process. If multiple interpreters were involved, I could see this test failing. Otherwise, it is puzzling.
This PR does no refcounting, allocation or deallocation. My guess is that this PR is exposing an already existing miscounting of references when a recursion error occurs. Just a guess though.
The problem doesn't appear to be an issue with running the test suite as a single process - Android isn't affected in CI, I can't reproduce the issue on my own macOS machine running a single-process run locally.
However, I also can't reliably reproduce the problem locally on iOS. Running the fully test suite locally, this test passes reliably.
While I can't tell why this test is failing only for iOS in CI, the precondition is incorrect, as the number of allocated blocks is per-process and the reference count is per interpreter.
The comment in C function sys_getallocatedblocks_impl says "It might make sense to return the count for just the current interpreter." We should do that.
The PR disabling the precondition has been merged, so I'm going to close this issue. The fix to get_sysallocatedblocks_impl can be handled separately, and the pre-condition re-enabled on iOS if that approach works.
Bug report
Bug description:
#130007 introduced a change to the handling of C stack limits. This change intermittently causes the
test_sys.SysModuleTest.get_allocated_blocks()
test to fail:The exact values vary, but they're usually within ~500 or so.
On the test re-run, the values are different:
(again, varying between test runs by ~500 or so).
@markshannon commented on the original PR:
The problem doesn't appear to be an issue with running the test suite as a single process - Android isn't affected in CI, I can't reproduce the issue on my own macOS machine running a single-process run locally.
However, I also can't reliably reproduce the problem locally on iOS. Running the fully test suite locally, this test passes reliably.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Other
Linked PRs
The text was updated successfully, but these errors were encountered: