test_class.test_detach_materialized_dict_no_memory() fails randomly on the Free Threading macOS CI · Issue #157429 · python/cpython · GitHub

macOS (free-threading) / build and test (macos-26) build: https://github.com/python/cpython/actions/runs/34757893189/job/103725487469?pr=157417

FAIL: test_detach_materialized_dict_no_memory (test.test_class.TestInlineValues.test_detach_materialized_dict_no_memory)
----------------------------------------------------------------------
test.support.isolation._RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/Users/runner/work/cpython/cpython/Lib/test/support/__init__.py", line 1374, in internal
    return test(*args, **kwargs)
AssertionError: the dictionary was not cleared
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/runner/work/cpython/cpython/Lib/test/support/__init__.py", line 1374, in internal
    return test(*args, **kwargs)
AssertionError: test failed in the subprocess

Linked PRs

gh-157429: Make test_detach_materialized_dict_no_memory deterministic #157444

I'm not sure why it's much more likely to happen today, but I think this is pre-existing flakiness in the test. I think (with some AI assistance to be fair) it might be that GC is firing at the eval-breaker check right after set_nomemory returns and that causes an unraisable MemoryError during collection.

Maybe as a hack we could disable GC during the loop @serhiy-storchaka added in gh-155146?

A more elaborate fix would involve writing a C helper.

I could not reproduce it, but the only thing that can run between set_nomemory() returning and del a is the eval breaker check after the call. On free-threading builds that is not only the GC, but also processing of deferred frees (QSBR) and refcount merges, and all of them can allocate. And the unraisable MemoryError may then come from deallocating some other object.

#157444 adds _testcapi.call_with_nomemory() which arms the failure, calls a C function and removes the hooks with no bytecode in between, so nothing else can consume the failing allocation. The test drops the last reference with list.clear via this helper, and its failure message now lists what was seen for every n, so if it fails again we will know what fired.

gh-157429: Make test_detach_materialized_dict_no_memory deterministic (…

test_class.test_detach_materialized_dict_no_memory() fails randomly on the Free Threading macOS CI · Issue #157429 · python/cpython · GitHub

Repository navigation

test_class.test_detach_materialized_dict_no_memory() fails randomly on the Free Threading macOS CI #157429

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

test_class.test_detach_materialized_dict_no_memory() fails randomly on the Free Threading macOS CI · Issue #157429 · python/cpython · GitHub

Repository navigation

test_class.test_detach_materialized_dict_no_memory() fails randomly on the Free Threading macOS CI #157429

Description

Linked PRs

Activity

ngoldbaum commented on Sep 13, 2026

serhiy-storchaka commented on Sep 13, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions