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

Terry Reedy tjreedy at udel.edu
Wed May 12 11:37:24 EDT 2004


"Tim Peters" <tim.one at comcast.net> wrote in message
news:E1BNkbA-0003fY-8g at mail.python.org...
> Verifying what, precisely?  Some things can clearly be checked.  For
> examples, that all opcodes are defined, that no LOAD_CONST tries to index
> beyond the actual length of co_consts, and that no jump tries to branch
into
> the middle of some multi-byte opcode sequence  Violations of such
> simple-to-check kinds of things are what cause segfaults most often when
> handing the PVM nonsense bytes.  Harder to do is flow-sensitive eval
stack
> simulation, to ensure that no path through the code can push more on the
> eval stack than was allocated for it, and that there's enough stuff on
the
> stack at each point to satisfy each opcode that requires accessing the
eval
> stack.
>
> A subset of what the Java bytecode verifier does is quite doable:

Since I opened this somewhat hidden hornet's nest, the (newby) author of
the code that caused the offending crash has admitted on clp that the code
he fed to new.code was standard ascii Python code, not bytecode.  In other
words, something that almost certainly looked like gibberish to ceval.  The
limited goal of usually rejecting such 'random' byte strings, if adopted,
*should* be doable since such should have many errors and we only need to
catch one, not all, to reject.

Protecting against maliciously or otherwise modified compiler output is a
whole different game.  Too bad there is no system-independent way to
'catch' crashes and exit more gracefully than usually useless core dumps,
blue screens of death, or whatever.

Terry J. Reedy






More information about the Python-Dev mailing list