[Python-Dev] Is core dump always a bug? Advice requested (original) (raw)
Armin Rigo arigo at tunes.org
Thu May 13 04:54:01 EDT 2004
- Previous message: [Python-Dev] Is core dump always a bug? Advice requested
- Next message: [Python-Dev] Is core dump always a bug? Advice requested
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Is core dump always a bug? Advice requested
- Next message: [Python-Dev] Is core dump always a bug? Advice requested
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]