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

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 LOADCONST tries to index beyond the actual length of coconsts, 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