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 — 3.15: gh-142349 backport moves `c_stack_refs` in `_PyThreadStateImpl`, breaking greenlet's rc2-built wheels · Issue #158593 · python/cpython

3.15: gh-142349 backport moves c_stack_refs in _PyThreadStateImpl, breaking greenlet's rc2-built wheels #158593

New issue
Copy link
New issue
Copy link
Closed
Closed
3.15: gh-142349 backport moves c_stack_refs in _PyThreadStateImpl, breaking greenlet's rc2-built wheels#158593
Copy link
Labels
3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesrelease-blockertype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@ddorian
ddorian
opened on Oct 2, 2026
Issue body actions

Bug report

Because in RC1 release you said, the following bug is only an issue for wheels built on RC2 and doesn't reproduce on new builds from source:

▎ "There will be no ABI changes from this point forward in the 3.15 series"
▎ "Any binary wheels built against Python 3.15.0 release candidates will work with future versions of Python 3.15."


The 3.15 backport of gh-142349 (#158569, 021f634) adds lazy_imports in the middle of _PyThreadStateImpl. On free-threaded builds this moves c_stack_refs from offset 1088 to 1096.

greenlet reads c_stack_refs on every switch. Its cp315t wheels on PyPI were built against rc2, so on the current 3.15 branch they read the wrong field and grow memory until the process is killed. In a pytest run this pushed a 64 GB machine into an OOM in under a minute.

Building greenlet from source fixes it.

Could lazy_imports go at the end of the struct, so wheels built against rc1/rc2 keep working on 3.15.0?

The script below runs one switch in a child process and kills it past 1 GiB:

uv run --python <free-threaded build of the 3.15 branch> greenlet_315_repro.py 

greenlet_315_repro.py

cc @pablogsal @hugovk

CPython versions tested on:

3.15

Operating systems tested on:

Linux

Linked PRs

  • gh-158593: Move lazy_imports field to end of _PyThreadStateImpl #158594
  • [3.15] GH-158593: Fix ABI compatibility with earlier RCs #158595
  • [3.15] gh-158593: Move lazy_imports field to end of _PyThreadStateImpl #158596

Activity

  1. ddorian
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    on Oct 2, 2026
  2. JelleZijlstra
    added
    release-blocker
    on Oct 2, 2026
  3. github-project-automation
    added this to Release and Deferred blockers 🚫on Oct 2, 2026
  4. hugovk
    added
    3.15bugs and security fixesbugs and security fixes
    3.16new features, bugs and security fixesnew features, bugs and security fixes
    on Oct 2, 2026
  5. hugovk commented on Oct 2, 2026

    @hugovk
    hugovk
    on Oct 2, 2026
    Member
    More actions

    I've opened PR #158594.

  6. pablogsal commented on Oct 2, 2026

    @pablogsal
    pablogsal
    on Oct 2, 2026
    Member
    More actions

    Wait the thread state is NOT part of the public ABI and therefore not an ABI change.

  7. hugovk
    added a commit that references this issue on Oct 2, 2026

    [3.15] GH-158593: Fix ABI compatibility with earlier RCs (#158595)

    202388a
  8. hugovk
    closed this as completedon Oct 2, 2026
  9. hugovk commented on Oct 2, 2026

    @hugovk
    hugovk
    on Oct 2, 2026
    Member
    More actions

    It's easy enough to fix, but we've only done so for 3.15, and not main, so greenlet has some time to move away from using these internals.

    @ddorian Please open an issue for greenlet. The first 3.16 alpha will be out in a couple of weeks, so you'll be able to start testing against that in GitHub Actions.

  10. github-project-automation
    moved this from Todo to Done in Release and Deferred blockers 🚫on Oct 2, 2026
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

    3.15bugs and security fixesbugs and security fixes3.16new features, bugs and security fixesnew features, bugs and security fixesrelease-blockertype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    • Release and Deferred blockers 🚫
      Status
      Done
      Show more project fields

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402520 — 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.