Skip to content

Hitting Assert for Managed Static Types During Subinterpreter Finalization #120765

Closed as duplicate
Closed as duplicate
Hitting Assert for Managed Static Types During Subinterpreter Finalization#120765
Assignees
ericsnowcurrently
Labels
3.13only security fixes3.14bugs and security fixestopic-subinterpreterstype-crashA hard crash of the interpreter, possibly with a core dump

Description

@ericsnowcurrently
ericsnowcurrently
opened on Jun 19, 2024

Bug report

Bug description:

$ ./python
Python 3.14.0a0 (heads/main:9f741e55c16, Jun 18 2024, 16:38:50) [GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import _interpreters
>>> _interpreters.create()
>>> exit
python: Objects/typeobject.c:307: managed_static_type_state_clear: Assertion `!_PyRuntime.types.managed_static.types[full_index].interp_count' failed.
Aborted (core dumped)

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Activity

  1. ericsnowcurrently
    added
    type-bugAn unexpected behavior, bug, or error
    topic-subinterpreters
    3.13only security fixes
    3.14bugs and security fixes
    on Jun 19, 2024
  2. ericsnowcurrently
    self-assigned this
    on Jun 19, 2024
  3. github-project-automation
    added this to Subinterpreterson Jun 19, 2024
  4. github-project-automation
    moved this to Todo in Subinterpreterson Jun 19, 2024
  5. ericsnowcurrently
    added
    type-crashA hard crash of the interpreter, possibly with a core dump
    and removed
    type-bugAn unexpected behavior, bug, or error
    on Jun 19, 2024

  6. ericsnowcurrently commented on Jun 19, 2024

    @ericsnowcurrently
    ericsnowcurrently
    on Jun 19, 2024
    MemberAuthor

    Ah, I see the problem. The code currently assumes that when the main interpreter is finalized, that no other interpreters are still around. I'll have to fix that.

  7. Eclips4 commented on Jun 20, 2024

    @Eclips4
    Eclips4
    on Jun 20, 2024
    Member

    Isn't it a duplicate of #113433?

  8. ericsnowcurrently commented on Jun 20, 2024

    @ericsnowcurrently
    ericsnowcurrently
    on Jun 20, 2024
    MemberAuthor

    It's definitely closely related (and the fix for gh-113433 will fix it), but it is a slightly different problem.

  9. miss-islington
    added a commit that references this issue on Jun 26, 2024

    pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…

    8c13544
  10. ericsnowcurrently
    added 2 commits that reference this issue on Jun 26, 2024

    gh-113433: Automatically Clean Up Subinterpreters in Py_Finalize() (g…

    4be1f37

    [3.13] gh-113433: Automatically Clean Up Subinterpreters in Py_Finali…

    c839974
  11. ericsnowcurrently
    closed this as completedon Jun 26, 2024
  12. github-project-automation
    moved this from Todo to Done in Subinterpreterson Jun 26, 2024
  13. mrahtz
    added a commit that references this issue on Jun 30, 2024

    pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…

    7aa0f5d
  14. noahbkim
    added a commit that references this issue on Jul 11, 2024

    pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…

    04ea2e9
  15. estyxx
    added a commit that references this issue on Jul 17, 2024

    pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…

    1a151b0
  16. serhiy-storchaka
    closed this as a duplicateof test_interpreters: test_create_many_threaded() failed on FreeBSD: log: RuntimeError: interpreter creation failed #109700 on Jul 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.13only security fixes3.14bugs and security fixestopic-subinterpreterstype-crashA hard crash of the interpreter, possibly with a core dump

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions