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.

Sign up for GitHub

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

Jump to bottom

Hitting Assert for Managed Static Types During Subinterpreter Finalization #120765

Closed
ericsnowcurrently opened this issue Jun 19, 2024 · 3 comments
Closed

Hitting Assert for Managed Static Types During Subinterpreter Finalization #120765

ericsnowcurrently opened this issue Jun 19, 2024 · 3 comments
Assignees
@ericsnowcurrently
Labels
3.13 bugs and security fixes 3.14 new features, bugs and security fixes topic-subinterpreters type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@ericsnowcurrently
Copy link
Member

ericsnowcurrently commented Jun 19, 2024 •
edited by github-actions bot
Loading

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
@ericsnowcurrently ericsnowcurrently added type-bug An unexpected behavior, bug, or error topic-subinterpreters 3.13 bugs and security fixes 3.14 new features, bugs and security fixes labels Jun 19, 2024
@ericsnowcurrently ericsnowcurrently self-assigned this Jun 19, 2024
@ericsnowcurrently ericsnowcurrently added type-crash A hard crash of the interpreter, possibly with a core dump and removed type-bug An unexpected behavior, bug, or error labels Jun 19, 2024
@ericsnowcurrently
Copy link
Member Author

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.

@Eclips4
Copy link
Member

Eclips4 commented Jun 20, 2024

Isn't it a duplicate of #113433?

@ericsnowcurrently
Copy link
Member Author

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

This was referenced Jun 26, 2024
Merged
Closed
miss-islington pushed a commit to miss-islington/cpython that referenced this issue Jun 26, 2024
@ericsnowcurrently @miss-islington
pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…
8c13544 
…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 <ericsnowcurrently@gmail.com>
@miss-islington miss-islington mentioned this issue Jun 26, 2024
Merged
ericsnowcurrently added a commit that referenced this issue Jun 26, 2024
@ericsnowcurrently
gh-113433: Automatically Clean Up Subinterpreters in Py_Finalize() (g…
4be1f37 
…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
@miss-islington @ericsnowcurrently
[3.13] gh-113433: Automatically Clean Up Subinterpreters in Py_Finali…
c839974 
…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 <ericsnowcurrently@gmail.com>
@github-project-automation github-project-automation bot moved this from Todo to Done in Subinterpreters Jun 26, 2024
mrahtz pushed a commit to mrahtz/cpython that referenced this issue Jun 30, 2024
@ericsnowcurrently @mrahtz
pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…
7aa0f5d 
…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
@ericsnowcurrently @noahbkim
pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…
04ea2e9 
…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
@ericsnowcurrently @estyxx
pythongh-113433: Automatically Clean Up Subinterpreters in Py_Finaliz…
1a151b0 
…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
Assignees

@ericsnowcurrently ericsnowcurrently

Labels
3.13 bugs and security fixes 3.14 new features, bugs and security fixes topic-subinterpreters type-crash A hard crash of the interpreter, possibly with a core dump
Projects
Subinterpreters
Status: Done
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ericsnowcurrently @Eclips4