When Interpreter.call() returns a value, that value is pickled in the callee interpreter and reconstructed (unpickled) in the calling interpreter on the way out of the cross-interpreter session, inside _PyXI_Exit() (Python/crossinterp.c). If the reconstruction step raises — e.g. the returned object's __reduce__ produces a callable that raises during unpickling — the raised exception is left set while _PyXI_Exit() applies its "preserve failure" handling. On a debug build this trips assert(!_PyErr_Occurred(tstate)) and aborts the process (SIGABRT); on a release build the stale exception is clobbered and the resulting error state is wrong.
Reproduction (debug build)
import sys, os, tempfile, importlib
from textwrap import dedent
from concurrent import interpreters
d = tempfile.mkdtemp(); sys.path.insert(0, d)
with open(os.path.join(d, "b.py"), "w") as f:
f.write(dedent('''
def _boom():
raise ValueError("unpickling failed")
class Bomb:
def __reduce__(self):
return (_boom, ())
def mk():
return Bomb()
'''))
m = importlib.import_module("b")
ip = interpreters.create()
ip.prepare_main(_d=d)
ip.exec("import sys; sys.path.insert(0, _d); import b")
ip.call(m.mk) # debug build: Assertion failed in _PyXI_Exit -> SIGABRT
This affects only the call() path (and any other _PyXI_Enter/_PyXI_Exit-bracketed result-preserve path). Queue/channel get()/recv() and exec() do not go through this path and are unaffected. Since call() runs the caller's own code in the subinterpreter, this is a robustness / crash bug, not a security issue.
Expected: call() should raise a normal Python exception instead of aborting.
Fix
Have the reconstruction-failure branch consume the live exception and propagate it as the failure, mirroring how the active-session _pop_preserved path already routes errors through capture_session_error. With the fix, call() raises NotShareableError with the underlying error reachable as the cause. A self-contained regression test is added in Lib/test/test_interpreters/test_api.py.
Affected versions
main only. The result-preserve machinery (_PyXI_Preserve / _finish_preserved, gh-133484) and the xi_error_* error-handling rewrite (gh-135369) that this touches both landed after the 3.14.0b1 freeze, so the affected code path does not exist on 3.14 or earlier.
Related
A separate, distinct crossinterp NULL dereference on the queue/channel receive path is tracked in #151862.
Linked PR
A PR follows.
Linked PRs
When
Interpreter.call()returns a value, that value is pickled in the callee interpreter and reconstructed (unpickled) in the calling interpreter on the way out of the cross-interpreter session, inside_PyXI_Exit()(Python/crossinterp.c). If the reconstruction step raises — e.g. the returned object's__reduce__produces a callable that raises during unpickling — the raised exception is left set while_PyXI_Exit()applies its "preserve failure" handling. On a debug build this tripsassert(!_PyErr_Occurred(tstate))and aborts the process (SIGABRT); on a release build the stale exception is clobbered and the resulting error state is wrong.Reproduction (debug build)
This affects only the
call()path (and any other_PyXI_Enter/_PyXI_Exit-bracketed result-preserve path). Queue/channelget()/recv()andexec()do not go through this path and are unaffected. Sincecall()runs the caller's own code in the subinterpreter, this is a robustness / crash bug, not a security issue.Expected:
call()should raise a normal Python exception instead of aborting.Fix
Have the reconstruction-failure branch consume the live exception and propagate it as the failure, mirroring how the active-session
_pop_preservedpath already routes errors throughcapture_session_error. With the fix,call()raisesNotShareableErrorwith the underlying error reachable as the cause. A self-contained regression test is added inLib/test/test_interpreters/test_api.py.Affected versions
mainonly. The result-preserve machinery (_PyXI_Preserve/_finish_preserved, gh-133484) and thexi_error_*error-handling rewrite (gh-135369) that this touches both landed after the 3.14.0b1 freeze, so the affected code path does not exist on 3.14 or earlier.Related
A separate, distinct crossinterp
NULLdereference on the queue/channel receive path is tracked in #151862.Linked PR
A PR follows.
Linked PRs