GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — test_detach_materialized_dict_no_memory depends on the exact number of allocations · Issue #155146 · python/cpython

test_detach_materialized_dict_no_memory depends on the exact number of allocations #155146

New issue
Copy link
New issue
Copy link
Closed
Closed
test_detach_materialized_dict_no_memory depends on the exact number of allocations#155146
Copy link
Labels
testsTests in the Lib/test dirTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@serhiy-storchaka
serhiy-storchaka
opened on Aug 4, 2026
Issue body actions

Bug report

test_class.TestInlineValues.test_detach_materialized_dict_no_memory (added in gh-124547) uses _testcapi.set_nomemory(0, 1) to fail the first allocation after that call, and assumes that this is the allocation which detaches the instance dictionary from the object. But set_nomemory() hooks all three allocator domains, so any other allocation which happens first consumes the single failure.

The target is one allocation wide. Failing the n-th allocation instead on Linux: n=0 works as intended, n=1..4 kill the process with MemoryError, and for n>=5 no MemoryError occurs during deallocation at all.

The test subprocess imports only test.support and _testcapi, so any change of what test.support allocates at import time can shift the sequence.

#155120 is such a change: it adds three functions and a constant to Lib/test/support/__init__.py, none of which is used by this test. With it the test fails on the Windows / Build and test (x64, tail-call) job:

    assert False, "KeyError not raised"
AssertionError: KeyError not raised

MemoryError was reported as unraisable during deallocation, but the dictionary was not cleared, because the failing allocation was not the one in the detach code. This is deterministic — 3 failures out of 3, including a re-run of the same commit — while the same job passes on the last 6 commits on main and on the other recent pull requests I checked. It does not reproduce on Linux, nor on the other Windows configurations.

The tested invariant is correct, only the way it is tested is fragile. I propose to try to fail each of the first allocations and to accept the first one which fails in the detach code.

Linked PRs

  • gh-155146: Do not depend on the exact number of allocations in test_class #155150
  • [3.15] gh-155146: Do not depend on the exact number of allocations in test_class (GH-155150) #155155
  • [3.14] gh-155146: Do not depend on the exact number of allocations in test_class (GH-155150) #155156
  • [3.13] gh-155146: Do not depend on the exact number of allocations in test_class (GH-155150) #155157
Reacted by Sergey B Kirpichev

Activity

  1. serhiy-storchaka
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    testsTests in the Lib/test dirTests in the Lib/test dir
    on Aug 4, 2026
  2. serhiy-storchaka
    added 3 commits that reference this issue on Aug 4, 2026

    gh-155146: Do not depend on the exact number of allocations in test_c…

    416c346

    [3.13] gh-155146: Do not depend on the exact number of allocations in…

    42b23da

    [3.14] gh-155146: Do not depend on the exact number of allocations in…

    12ac1ed
  3. deadlovelll
    added a commit that references this issue on Aug 5, 2026

    [3.14] pythongh-155146: Do not depend on the exact number of allocati…

    6163e33
  4. hugovk
    added a commit that references this issue on Aug 8, 2026

    [3.15] gh-155146: Do not depend on the exact number of allocations in…

    6c406a4
  5. hugovk
    closed this as completedon Aug 8, 2026
  6. mbeijen
    added a commit that references this issue on Aug 14, 2026

    pythongh-155146: Do not depend on the exact number of allocations in …

    198a4fe
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    testsTests in the Lib/test dirTests in the Lib/test dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.