This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author xdegaye
Recipients benjamin.peterson, georg.brandl, jcea, serhiy.storchaka, vstinner, xdegaye
Date 2018-02-28.07:03:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1519801414.32.0.467229070634.issue17288@psf.upfronthosting.co.za>
In-reply-to
Content
xdegaye wrote:
> An explanation should be given for the behavior of 3.7 and 3.8 in the jump.py case.

In 3.7 when running jump.py as in msg183254, Python aborts with a frame stack overflow.  The reason is that when the generator is resumed after the jump, its send() method is called with an argument and pushes the argument on the frame stack (i.e. f->f_stacktop - f->f_valuestack == 1 in gen_send_ex() before the call to PyEval_EvalFrameEx()). This argument is supposed to be popped by the first instruction executed by the generator which is expected to be YIELD_VALUE but, because of the jump, f->f_lasti is now 0 and the send() argument is not popped.  Hence the stack overflow.

When LLTRACE is undefined in ceval.c, stack oveflow checking is disabled. I have checked with gdb that, in that case, when YIELD_VALUE is about to be executed then STACK_LEVEL() is 3 instead of 1 and therefore YIELD_VALUE does not pop the right value from the stack. The stack is indeed corrupted.

So there are two reasons for forbiddig to jump from a yield statement:
* the ceval loop has exited and the jump is not allowing the user to jump to another line
* after the jump, resuming a generator corrupts the frame stack
History
Date User Action Args
2018-02-28 07:03:34xdegayesetrecipients: + xdegaye, georg.brandl, jcea, vstinner, benjamin.peterson, serhiy.storchaka
2018-02-28 07:03:34xdegayesetmessageid: <1519801414.32.0.467229070634.issue17288@psf.upfronthosting.co.za>
2018-02-28 07:03:34xdegayelinkissue17288 messages
2018-02-28 07:03:33xdegayecreate