Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash of interpreter due to unclosed sub-interpreters #113433

Closed
Eclips4 opened this issue Dec 23, 2023 · 3 comments
Closed

Crash of interpreter due to unclosed sub-interpreters #113433

Eclips4 opened this issue Dec 23, 2023 · 3 comments
Labels
topic-subinterpreters type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@Eclips4
Copy link
Member

Eclips4 commented Dec 23, 2023

Crash report

Reproducer:

import _xxsubinterpreters as interp

interp_id = interp.create()

Trace:

Fatal Python error: PyInterpreterState_Delete: remaining subinterpreters
Python runtime state: finalizing (tstate=0x00005576a7f343e0)

Aborted

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Linked PRs

@Eclips4 Eclips4 added type-crash A hard crash of the interpreter, possibly with a core dump topic-subinterpreters labels Dec 23, 2023
@Eclips4
Copy link
Member Author

Eclips4 commented Dec 23, 2023

Bisected to 86a77f4
cc @ericsnowcurrently

@ericsnowcurrently
Copy link
Member

Sorry for the delay. I'll try to take a look in the next day or two.

miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 26, 2024
…e() (pythongh-121060)

This change makes things a little less painful for some users.  It also fixes a failing assert (pythongh-120765), by making sure all subinterpreters are destroyed before the main interpreter.  As part of that, we make sure Py_Finalize() always runs with the main interpreter active.
(cherry picked from commit 4be1f37)

Co-authored-by: Eric Snow <[email protected]>
ericsnowcurrently added a commit that referenced this issue Jun 26, 2024
…h-121060)

This change makes things a little less painful for some users.  It also fixes a failing assert (gh-120765), by making sure all subinterpreters are destroyed before the main interpreter.  As part of that, we make sure Py_Finalize() always runs with the main interpreter active.
ericsnowcurrently added a commit that referenced this issue Jun 26, 2024
…ze() (gh-121067)

This change makes things a little less painful for some users.  It also fixes a failing assert (gh-120765), by making sure all subinterpreters are destroyed before the main interpreter.  As part of that, we make sure Py_Finalize() always runs with the main interpreter active.

(cherry picked from commit 4be1f37, AKA gh-121060)

Co-authored-by: Eric Snow <[email protected]>
@ericsnowcurrently
Copy link
Member

This should be all sorted for main and 3.13. Backporting to 3.12 isn't really an option.

mrahtz pushed a commit to mrahtz/cpython that referenced this issue Jun 30, 2024
…e() (pythongh-121060)

This change makes things a little less painful for some users.  It also fixes a failing assert (pythongh-120765), by making sure all subinterpreters are destroyed before the main interpreter.  As part of that, we make sure Py_Finalize() always runs with the main interpreter active.
noahbkim pushed a commit to hudson-trading/cpython that referenced this issue Jul 11, 2024
…e() (pythongh-121060)

This change makes things a little less painful for some users.  It also fixes a failing assert (pythongh-120765), by making sure all subinterpreters are destroyed before the main interpreter.  As part of that, we make sure Py_Finalize() always runs with the main interpreter active.
estyxx pushed a commit to estyxx/cpython that referenced this issue Jul 17, 2024
…e() (pythongh-121060)

This change makes things a little less painful for some users.  It also fixes a failing assert (pythongh-120765), by making sure all subinterpreters are destroyed before the main interpreter.  As part of that, we make sure Py_Finalize() always runs with the main interpreter active.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-subinterpreters type-crash A hard crash of the interpreter, possibly with a core dump
Projects
Status: Done
Development

No branches or pull requests

2 participants