[issue29587] Generator/coroutine 'throw' discards exc_info state, which is bad
STINNER Victor
report at bugs.python.org
Mon May 4 10:13:00 EDT 2020
STINNER Victor <vstinner at python.org> added the comment:
tl; dr I wrote PR 19902 to remove the "XXX" comment.
--
Commit 21893fbb74e8fde2931fbed9b511e2a41362b1ab adds the following code:
/* XXX It seems like we shouldn't have to check not equal to Py_None
here because exc_type should only ever be a class. But not including
this check was causing crashes on certain tests e.g. on Fedora. */
if (gen->gi_exc_state.exc_type && gen->gi_exc_state.exc_type != Py_None) { ... }
I don't think that you should mention "Fedora" as a platform impacted by this issue: all platforms should be affected. It's just unclear why the issue was first seen on Fedora.
gen_send_ex() copies tstate->exc_info to gen->gi_exc_state.
tstate->exc_info->exc_type is set at least in the following 3 places in CPython code base:
* ceval.c: POP_EXCEPT opcode: exc_info->exc_type = POP();
* ceval.c: UNWIND_EXCEPT_HANDLER() macro: exc_info->exc_type = POP();
* errors.c: PyErr_SetExcInfo()
I saw in practice POP_EXCEPT and UNWIND_EXCEPT_HANDLER() setting exc_info->exc_type to Py_None (I didn't test PyErr_SetExcInfo()).
_PyErr_GetTopmostException() also handles exc_info->exc_type == Py_None case:
_PyErr_StackItem *
_PyErr_GetTopmostException(PyThreadState *tstate)
{
_PyErr_StackItem *exc_info = tstate->exc_info;
while ((exc_info->exc_type == NULL || exc_info->exc_type == Py_None) &&
exc_info->previous_item != NULL)
{
exc_info = exc_info->previous_item;
}
return exc_info;
}
--
So exc_type=None is not a bug, but it's done on purpose.
If you don't want to get None in genobject.c, we should modify all places which set tstate->exc_info->exc_type. Problem: the structure currently exposed in the public C API (bpo-40429), and I wouldn't be surprised if Cython or greenlet modify tstate->exc_info directly.
----------
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29587>
_______________________________________
More information about the Python-bugs-list
mailing list