Description

ZeroIntensity

opened on Feb 8, 2026

Issue body actions

Crash report

What happened?

I found this while investigating #138045.

If a PyInit_ function raises an exception when imported from a subinterpreter, the process will crash. For example, if you modify xxsubtyppe.c to raise an exception in its PyInit and then import it from a subinterpreter, you'll see a crash:

diff --git a/Modules/xxsubtype.c b/Modules/xxsubtype.c
index a8a1417f40e..57a5ef75eb7 100644
--- a/Modules/xxsubtype.c
+++ b/Modules/xxsubtype.c
@@ -324,5 +324,6 @@ static struct PyModuleDef xxsubtypemodule = {
 PyMODINIT_FUNC
 PyInit_xxsubtype(void)
 {
-    return PyModuleDef_Init(&xxsubtypemodule);
+    PyErr_SetString(PyExc_TypeError, "whatever");
+    return NULL;
 }

from concurrent import interpreters

interp = interpreters.create()
interp.exec("import xxsubtype")  # Crash!

This isn't usually a problem for multi-phase extensions, because PyModuleDef_Init doesn't fail with an exception (except sometimes on the free-threaded build, but that's rare), but this does happen for single-phase extensions. Single-phase extension modules do not support loading in subinterpreters, but attempting to load them from a subinterpreter should raise an exception rather than crash the interpreter.

I believe the problem lies here:

cpython/Python/import.c

Lines 2178 to 2196 in d736349

	main_finally:
	/* Switch back to the subinterpreter. */
	if (switched) {
	assert(main_tstate != tstate);
	switch_back_from_main_interpreter(tstate, main_tstate, mod);
	/* Any module we got from the init function will have to be
	* reloaded in the subinterpreter. */
	mod = NULL;
	}
	/*****************************************************************/
	/* At this point we are back to the interpreter we started with. */
	/*****************************************************************/
	/* Finally we handle the error return from _PyImport_RunModInitFunc(). */
	if (rc < 0) {
	_Py_ext_module_loader_result_apply_error(&res, name_buf);
	goto error;
	}

The exception object raised by the PyInit_ function is always owned by the main interpreter, but the exception is raised from the subinterpreter, which breaks things. There's not a clean way to raise the exception in the calling interpreter, so I think the best solution is to print the exception as unraisable in the main interpreter, and then raise some sort of blanket exception in the calling interpreter.

CPython versions tested on:

CPython main branch

Operating systems tested on:

Linux

Output from running 'python -VV' on the command line:

No response

Linked PRs

• gh-144601: Avoid sharing exception objects raised in a PyInit function across multiple interpreters #144602
• [3.14] gh-144601: Avoid sharing exception objects raised in a PyInit function across multiple interpreters (GH-144602) #144633
• [3.14] gh-144601: Use _testmultiphase instead of _testsinglephase in test_importlib #144769
• [3.13] gh-144601: Use _testmultiphase instead of _testsinglephase in test_importlib (GH-144769) #144877
• [3.13] gh-144601: Avoid sharing exception objects raised in a PyInit function across multiple interpreters (GH-144602) #144880

Activity

1. ZeroIntensity

   self-assigned this

   on Feb 8, 2026
2. ZeroIntensity

   added

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   type-crashA hard crash of the interpreter, possibly with a core dumpA hard crash of the interpreter, possibly with a core dump

   topic-subinterpreters

   3.13only security fixesonly security fixes

   3.14bugs and security fixesbugs and security fixes

   3.15bugs and security fixesbugs and security fixes

   on Feb 8, 2026
3. github-project-automation

   moved this to Todo in Subinterpreterson Feb 8, 2026
4. github-project-automation

   added this to Subinterpreterson Feb 8, 2026
5. encukou

   added a commit that references this issue on Feb 9, 2026

   gh-144601: Avoid sharing exception objects raised in a `PyInit` funct…

   fd6b639
6. miss-islington

   added a commit that references this issue on Feb 9, 2026

   pythongh-144601: Avoid sharing exception objects raised in a `PyInit`…

   7725c61
7. jan-hasse commented on Feb 10, 2026

   

   jan-hasse

   on Feb 10, 2026

   More actions

   Would this be fixed (for single-phase extension) by #142979?
8. ZeroIntensity commented on Feb 10, 2026

   

   ZeroIntensity

   on Feb 10, 2026

   MemberAuthor

   More actions

   No, this is a separate bug. I noticed this while writing a test case for #142979.

   Reacted by jan-hasse
9. thunder-coding

   added a commit that references this issue on Feb 15, 2026

   pythongh-144601: Avoid sharing exception objects raised in a `PyInit`…

   bf9df37
10. encukou

    added a commit that references this issue on Feb 16, 2026

    [3.14] gh-144601: Use `_testmultiphase` instead of `_testsinglephase`…

    d148662
11. miss-islington

    added a commit that references this issue on Feb 16, 2026

    [3.14] pythongh-144601: Use `_testmultiphase` instead of `_testsingle…

    a48159f
12. ZeroIntensity

    added 5 commits that reference this issue on Feb 16, 2026

    [3.13] gh-144601: Use `_testmultiphase` instead of `_testsinglephase`…

    e701a5c

    [3.14] gh-144601: Avoid sharing exception objects raised in a `PyInit…

    907958c

    [3.13] pythongh-144601: Avoid sharing exception objects raised in a `…

    1b2c2a4

    [3.13] pythongh-144601: Avoid sharing exception objects raised in a `…

    b00f9b0

    [3.13] gh-144601: Avoid sharing exception objects raised in a `PyInit…

    9314ec2
13. ZeroIntensity

    closed this as completedon Feb 16, 2026
14. github-project-automation

    moved this from Todo to Done in Subinterpreterson Feb 16, 2026
15. ljfp

    added a commit that references this issue on Apr 25, 2026

    pythongh-144601: Avoid sharing exception objects raised in a `PyInit`…

    864dfa3

Issue actions