[Python-Dev] Is core dump always a bug? Advice requested

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; END_FINALLY 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?

> * POP_BLOCK 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 POP_BLOCK, 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.

> * MAKE_CLOSURE 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 MAKE_CLOSURE could be
> preceded by a BUILD_TUPLE to collect all free vars into a tuple
> (which is what MAKE_CLOSURE 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