[Python-Dev] Set-next-statement in Python debuggers

[Michael Hudson]

Richie Hindle <richie@entrian.com> writes:

> Hi,
> 
> [Guido]
> > Python should not include features (like writable code object
> > attributes) that can cause crashes when used inexpertly.
> 
> If I do implement this, I'll do it in such a way as to make crashes
> impossible (my first suggestion said that crashes would be possible, but I
> realise that was a mistake).  It'll verify that the new value of f_lasti
> is a valid bytecode position, and it'll either fix up the stack/blockstack
> or refuse to move the position in ways that would affect them.  (Armin, I
> guess that won't restrict you because you're doing this from C code?)

You can still cause crashes though: move f_lasti to point to a
STORE_NAME (say) without first executing the corresponding LOAD_CONST
(say).

Or just execute a LOAD_CONST over and over again until you fall off
the end of the stack.

> [Armin]
> > For safety I'd consider writing the
> > frame-object-modifying code in a C extension module, carefully
> > documented as "don't use this".
> 
> [Guido]
> > That's a reasonable solution: f_lasti should be read-only from Python
> > code, but you can write an extension that can write it.
> 
> I'd like to see pure Python debuggers (including pdb) have this feature.
> If it's safe to use, might it still be considered for inclusion?  (I can't
> guarantee I'll have the time to do it, but I'll try.)
> 
> I'm also coming to realise that it's not f_lasti I really want to change,
> but f_lineno.  The line number is the 'unit' that debuggers use - a
> debugger would set f_lineno, and f_lasti would be calculated and changed
> to the appropriate value.  I don't think that changes any of the arguments
> either way, except maybe to distance the idea a little from what Armin is
> doing.

This is a good point!  The scenarios I sketched above would be rather
harder (impossible?) to contrive in this situation.

Cheers,
M.

-- 
112. Computer Science is embarrassed by the computer.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html