Skip to content

Commit 49d0942

Browse files
njsmith1st1
authored andcommitted
[3.6] bpo-30039: Don't run signal handlers while resuming a yield from stack (GH-1081)
If we have a chain of generators/coroutines that are 'yield from'ing each other, then resuming the stack works like: - call send() on the outermost generator - this enters _PyEval_EvalFrameDefault, which re-executes the YIELD_FROM opcode - which calls send() on the next generator - which enters _PyEval_EvalFrameDefault, which re-executes the YIELD_FROM opcode - ...etc. However, every time we enter _PyEval_EvalFrameDefault, the first thing we do is to check for pending signals, and if there are any then we run the signal handler. And if it raises an exception, then we immediately propagate that exception *instead* of starting to execute bytecode. This means that e.g. a SIGINT at the wrong moment can "break the chain" – it can be raised in the middle of our yield from chain, with the bottom part of the stack abandoned for the garbage collector. The fix is pretty simple: there's already a special case in _PyEval_EvalFrameEx where it skips running signal handlers if the next opcode is SETUP_FINALLY. (I don't see how this accomplishes anything useful, but that's another story.) If we extend this check to also skip running signal handlers when the next opcode is YIELD_FROM, then that closes the hole – now the exception can only be raised at the innermost stack frame. This shouldn't have any performance implications, because the opcode check happens inside the "slow path" after we've already determined that there's a pending signal or something similar for us to process; the vast majority of the time this isn't true and the new check doesn't run at all.. (cherry picked from commit ab4413a)
1 parent 44944b6 commit 49d0942

File tree

4 files changed

+72
-4
lines changed

4 files changed

+72
-4
lines changed

Lib/test/test_generators.py

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,35 @@
1010

1111
from test import support
1212

13+
_testcapi = support.import_module('_testcapi')
14+
15+
16+
# This tests to make sure that if a SIGINT arrives just before we send into a
17+
# yield from chain, the KeyboardInterrupt is raised in the innermost
18+
# generator (see bpo-30039).
19+
class SignalAndYieldFromTest(unittest.TestCase):
20+
21+
def generator1(self):
22+
return (yield from self.generator2())
23+
24+
def generator2(self):
25+
try:
26+
yield
27+
except KeyboardInterrupt:
28+
return "PASSED"
29+
else:
30+
return "FAILED"
31+
32+
def test_raise_and_yield_from(self):
33+
gen = self.generator1()
34+
gen.send(None)
35+
try:
36+
_testcapi.raise_SIGINT_then_send_None(gen)
37+
except BaseException as _exc:
38+
exc = _exc
39+
self.assertIs(type(exc), StopIteration)
40+
self.assertEqual(exc.value, "PASSED")
41+
1342

1443
class FinalizationTest(unittest.TestCase):
1544

Misc/NEWS

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,11 @@ What's New in Python 3.6.2 release candidate 1?
1010
Core and Builtins
1111
-----------------
1212

13-
- bpo-12414: sys.getsizeof() on a code object now returns the sizes
13+
- bpo-30039: If a KeyboardInterrupt happens when the interpreter is in
14+
the middle of resuming a chain of nested 'yield from' or 'await'
15+
calls, it's now correctly delivered to the innermost frame.
16+
17+
bpo-12414: sys.getsizeof() on a code object now returns the sizes
1418
which includes the code struct and sizes of objects which it references.
1519
Patch by Dong-hee Na.
1620

Modules/_testcapimodule.c

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -4027,6 +4027,29 @@ dict_get_version(PyObject *self, PyObject *args)
40274027
}
40284028

40294029

4030+
static PyObject *
4031+
raise_SIGINT_then_send_None(PyObject *self, PyObject *args)
4032+
{
4033+
PyGenObject *gen;
4034+
4035+
if (!PyArg_ParseTuple(args, "O!", &PyGen_Type, &gen))
4036+
return NULL;
4037+
4038+
/* This is used in a test to check what happens if a signal arrives just
4039+
as we're in the process of entering a yield from chain (see
4040+
bpo-30039).
4041+
4042+
Needs to be done in C, because:
4043+
- we don't have a Python wrapper for raise()
4044+
- we need to make sure that the Python-level signal handler doesn't run
4045+
*before* we enter the generator frame, which is impossible in Python
4046+
because we check for signals before every bytecode operation.
4047+
*/
4048+
raise(SIGINT);
4049+
return _PyGen_Send(gen, Py_None);
4050+
}
4051+
4052+
40304053
static PyMethodDef TestMethods[] = {
40314054
{"raise_exception", raise_exception, METH_VARARGS},
40324055
{"raise_memoryerror", (PyCFunction)raise_memoryerror, METH_NOARGS},
@@ -4230,6 +4253,7 @@ static PyMethodDef TestMethods[] = {
42304253
{"tracemalloc_untrack", tracemalloc_untrack, METH_VARARGS},
42314254
{"tracemalloc_get_traceback", tracemalloc_get_traceback, METH_VARARGS},
42324255
{"dict_get_version", dict_get_version, METH_VARARGS},
4256+
{"raise_SIGINT_then_send_None", raise_SIGINT_then_send_None, METH_VARARGS},
42334257
{NULL, NULL} /* sentinel */
42344258
};
42354259

Python/ceval.c

Lines changed: 14 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1119,9 +1119,20 @@ _PyEval_EvalFrameDefault(PyFrameObject *f, int throwflag)
11191119
Py_MakePendingCalls() above. */
11201120

11211121
if (_Py_atomic_load_relaxed(&eval_breaker)) {
1122-
if (_Py_OPCODE(*next_instr) == SETUP_FINALLY) {
1123-
/* Make the last opcode before
1124-
a try: finally: block uninterruptible. */
1122+
if (_Py_OPCODE(*next_instr) == SETUP_FINALLY ||
1123+
_Py_OPCODE(*next_instr) == YIELD_FROM) {
1124+
/* Two cases where we skip running signal handlers and other
1125+
pending calls:
1126+
- If we're about to enter the try: of a try/finally (not
1127+
*very* useful, but might help in some cases and it's
1128+
traditional)
1129+
- If we're resuming a chain of nested 'yield from' or
1130+
'await' calls, then each frame is parked with YIELD_FROM
1131+
as its next opcode. If the user hit control-C we want to
1132+
wait until we've reached the innermost frame before
1133+
running the signal handler and raising KeyboardInterrupt
1134+
(see bpo-30039).
1135+
*/
11251136
goto fast_next_opcode;
11261137
}
11271138
if (_Py_atomic_load_relaxed(&pendingcalls_to_do)) {

0 commit comments

Comments
 (0)