Debug abort when calling <generator>.throw(StopIteration) on a generator that hasn't started yet

[stestagg]

Crash report

What happened?

In a debug build the following:

(_ for _ in ()).throw(StopIteration)

aborts with:

python3: Objects/genobject.c:318: PySendResult gen_send_ex2(PyGenObject *, PyObject *, PyObject **, int): Assertion `!PyErr_ExceptionMatches(PyExc_StopIteration)' failed.

Basically, calling generator.throw(StopIteration) on a generator that hasn't started yet triggers this.

In a non-debug build, the assert calls are not evaluated, but this very contrived example shows that there is a tortured violation of the PEP-479 fix that's possible (but unlikely to be seen in real code?):

Non-debug build script

from contextlib import contextmanager

@contextmanager
def transaction(level):
    print(f"begin {level}")
    try:
        yield
        print(f"commit {level}")
    except:
        print(f"rollback {level}")
        raise

def bad_helper(start_first):
    g = (_ for _ in (1, ))
    if start_first:
        next(g)
    return g.throw(StopIteration)

def rows(start_first):
    def next_row():
        with transaction(2):
            return bad_helper(start_first)
    return iter(next_row, None)

def run(start_first):
    print(f"Running with start_first={start_first}")
    try:
        with transaction(1):
            for row in rows(start_first):
                print(f"processed {row}")
    except BaseException as e:
        print(f"exception: {e!r}")
    finally:
        print("-=-=-=-=-=-  STOP -=-=-=-=-=-")

run(False)
run(True)

Running this outputs:

Running with start_first=False
begin 1
begin 2
rollback 2
commit 1
-=-=-=-=-=-  STOP -=-=-=-=-=-
Running with start_first=True
begin 1
begin 2
rollback 2
rollback 1
exception: RuntimeError('generator raised StopIteration')
-=-=-=-=-=-  STOP -=-=-=-=-=-

You can see that if the generator is started, both levels of transaction roll back correctly and we get a RuntimeError. But if the generator is not started, then tx2 is rolled back, but tx1 is committed, and no exception raised.

What's happening

• generator.throw() calls _gen_throw()
  

  cpython/Objects/genobject.c

  Line 756 in ecdef17

  return _gen_throw(gen, 1, typ, val, tb);

• _gen_throw sets the exception, then calls gen_throw_current_exception...:
  

  cpython/Objects/genobject.c

  Line 609 in ecdef17

  if (gen_send_ex2(gen, Py_None, &result, 1) == PYGEN_RETURN) {

• ... which calls gen_send_ex2 with exc=1:
  

  cpython/Objects/genobject.c

  Line 260 in ecdef17

  gen_send_ex2(PyGenObject *gen, PyObject *arg, PyObject **presult, int exc)

• gen_send_ex2 proceeds and around these lines:
  

  cpython/Objects/genobject.c

  Lines 277 to 281 in ecdef17

  	_PyErr_ChainStackItem();
  	}
  	EVAL_CALL_STAT_INC(EVAL_CALL_GENERATOR);
  	PyObject *result = _PyEval_EvalFrame(tstate, frame, exc);

  
  re-enters the frame with throwflag=1.
• Looking at the bytecode for the frame:

Disassembly of <code object <genexpr> at 0xfffff7291360, file "eval", line 1>:
  --                 RESUME                   4

1:16-1:21            LOAD_FAST                0 (.0)
1:16-1:21            GET_ITER                 0
1:?-1:?              RETURN_GENERATOR
1:?-1:?              POP_TOP
1:0-1:0      L1:     RESUME                   0
1:16-1:21    L2:     FOR_ITER                 7 (to L3)
1:11-1:12            STORE_FAST_LOAD_FAST    17 (_, _)
1:5-1:6              YIELD_VALUE              0
1:5-1:6              RESUME                   9
1:5-1:6              POP_TOP
1:5-1:6              JUMP_BACKWARD            9 (to L2)
1:16-1:21    L3:     END_FOR
1:16-1:21            POP_ITER
1:16-1:21            LOAD_COMMON_CONSTANT     7 (None)
1:16-1:21            RETURN_VALUE

  --         L4:     CALL_INTRINSIC_1         3 (INTRINSIC_STOPITERATION_ERROR)
  --                 RERAISE                  1
ExceptionTable:
  L1 to L4 -> L4 [2] lasti

We see that the INTRINSIC_STOPITERATION_ERROR call at L4 resolves to stopiteration_error
which is where the Runtime Error is instantiated, and set:

cpython/Python/intrinsics.c

Line 172 in ecdef17

PyObject *error = PyObject_CallOneArg(PyExc_RuntimeError, message);

• BUT if the iterator has not started, we haven't reached L1 yet (the initial resume wasn't called). so the Exception table does not cover those opcodes, and no stopiteration_error wrapper is called.

The assertions are doing their fine job and catching the problem here, but I'm reasonably confident that the root issue is actually the opcode wrapping.

I'm not sure what the fix should be here, maybe it's as simple as somehow moving L1 up one opcode?

Introduced by

f4adb975061874566766f7a67206cb7b0439bc11 is the first bad commit
commit f4adb975061874566766f7a67206cb7b0439bc11
Author: Mark Shannon <mark@hotpy.org>
Date:   Thu Nov 3 04:38:51 2022 -0700

    GH-96793: Implement PEP 479 in bytecode. (GH-99006)

    * Handle converting StopIteration to RuntimeError in bytecode.

    * Add custom instruction for converting StopIteration into RuntimeError.

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS, Linux

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

Python 3.14.5 (main, May 14 2026, 10:03:03) [GCC 15.2.1 20260209]