[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Neil Schemenauer report at bugs.python.org
Tue Dec 5 12:21:11 EST 2017


Neil Schemenauer <nas-python at arctrix.com> added the comment:

There is some more explanation in the PR and sample code.

We unwind, if we hit a finally fblock, we emit code of the body of it.  If inside the block, there is another return statement, we unwind again.  That causes an infinite loop in the compiler.

The commit 0610860 is a fix, I think.  I have a cleaner version but haven't pushed it yet.  There are still some remaining bugs though, caused by "return" in the finally body.  The problem as I see it is that "unwind_exception" in ceval pushes a EXCEPT_HANDLER fblock if we are inside a SETUP_EXCEPT or SETUP_FINALLY block.  If there is a return in the finally body, the compiler doesn't know if it should POP_BLOCK or not.  At least, that is my understanding now.

I think the best way forward is to split this patch into multiple parts.  I have a simple patch that changes fblockinfo to be a singly linked list (like blockinfo).  Next, I think we could change the exception opcodes to have a fixed stack effect (don't think that requires unwind to be done by compiler).  Rather than pushing three values for an exception, could we just build a tuple and push that?  Seems simpler to me vs having ROT_FOUR. Finally, we can tackle the compiler based unwind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________


More information about the Python-bugs-list mailing list