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

Armin Rigo arigo at tunes.org
Thu May 13 04:54:01 EDT 2004


Hello Michel,

On Wed, May 12, 2004 at 03:31:43PM -0500, Michel Pelletier wrote:
> But I belive Armin's argument that it equals the halting problem is
> incorrect.

You are missing my point.  Martin summarized what I intended to say: what is
equivalent to the halting problem is the question "can you say if the
following bytecode is going to execute some illegal opcode or not", which is a
purely theoretical question, as I am well aware.  The useful and checkable
question that interests us here is "does this bytecode follow the following
set of sane rules", for a well-specified set of rules.

> The net stack effect of bytecode can be verified regardless of the algorithm.

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

* '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).

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

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

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

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.


Armin



More information about the Python-Dev mailing list