[Python-Dev] Set-next-statement in Python debuggers (original) (raw)

Guido van Rossum guido@python.org
Wed, 09 Oct 2002 11:55:13 -0400

On Tue, 8 Oct 2002 richie@entrian.com wrote: > (...) A nasty consequence is that you can write Python code that causes > Python to seg-fault, but you have to be doing some fairly advanced stuff > for that to happen.

[Armin]

You can already crash the interpreter with pure Python code, for example via the new.code() constructor or by writing crappy .pyc files.

Yes, and I occasionally lose sleep over those. I definitely don't want to add more loopholes like that, and I'd like to fix those. In the past, the new module was optional for precisely this reason (and so is the dl module). I would like to have a check on .pyc files (or on unmarshalled code objects, really).

On Linux you can also open("/proc/self/mem", "w").

That doesn't mean that python should abandon the policy "a core dump is always considered Python's fault unless proven otherwise." Protecting you against using external tools may not be possible; but Python should not include features (like writable code object attributes) that can cause crashes when used inexpertly.

I don't think that people get their hands on frame objects by pure chance, but the possibility exists. Moreover, conditionally allowing changes to flasti is limiting and complex because of the stack and block stack. For safety I'd consider writing the frame-object-modifying code in a C extension module, carefully documented as "don't use this".

That's a reasonable solution: f_lasti should be read-only from Python code, but you can write an extension that can write it.

--Guido van Rossum (home page: http://www.python.org/~guido/)