[Python-Dev] Is core dump always a bug? Advice requested (original) (raw)

Guido van Rossum guido at python.org
Thu May 13 12:51:54 EDT 2004

Interestingly, it is not the case currently that for any bytecode position the stack depth is always the same. Here is a short review.

Thanks for this overview! I'd lost track of details like this over the years.

* 'finally' blocks are executed with one, two or three values pushed on the stack; ENDFINALLY will accordingly pop one, two or three values (depending on what the first popped value is).

This is easily fixed, if necessary -- but is it necessary?

* POPBLOCK will empty the value stack up to the position stored in the block stack's popped block, for no reason that I am aware of. I can't think of a compiler-emitted construct that uses this feature. Maybe it was introduced to implement 'break' as a jump to the POPBLOCK, but nowadays 'break' is more complicated anyway, using the general stack-unwinding and exception-handler-dispatching loop after the switch in ceval.c.

I can't remember what my intention was; I probably wasn't so sure that the stack level at the end of executing arbitrary code was always the same.

* MAKECLOSURE pops some cells to use for free variables, the number of which is found in the code object on the top of the stack.

This is a recent addition, and should have been done differently. It's not hard to fix, as you suggest (and as has been done in the AST branch).

I believe that all the other instructions have a stack effect that is either constant or computable from their oparg.

Me too.

If some long-term goal is to fix this, then MAKECLOSURE could be preceded by a BUILDTUPLE to collect all free vars into a tuple (which is what MAKECLOSURE does anyway). Fixing the 'finally' blocks isn't too complicated -- always push three values on the stack, possibly None's. A better 'fix' would be that the block stack could, as we discussed at PyCon, be replaced by a purely static structure in the code object.

Correct, I would like to see this happen. There's dynamic stuff here just to make the implementation easy rather than to support necessary dynamism. (The same could be said of some other parts of Python, but there we've come to love the dynamism -- for the most part anyway. ;-)

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list