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

Michael Hudson mwh at python.net
Thu May 13 05:40:26 EDT 2004


"Tim Peters" <tim.one at comcast.net> writes:

> Examples of things that aren't checked at all now in the PVM were given
> before, like the PVM doesn't check that it allocated enough stack space, or
> check that C-level indexing into the co_consts vector is in bounds.  Well,
> in the latter case, that is checked (at runtime, on every co_consts access)
> in a debug build, but not in a release build.

I think stack over/underflow is checked in a debug build too.

So here's a way to plug these holes: run a debug build the whole time
:-) It's only, what, a factor of 3 performance hit.

If people are seriously concerned about preventing Python coring in
all circumstances, we should look at the various ways of overflowing
the stack, too.  The recursion counter is a hack, and IMHO can't be
made to work sensibly.  For instance: list_sort() has quite a large
structure on the stack, so if you arrange to call it recursively it
falls off the end of the stack much much sooner than a simple Python
recursion.

I don't know what we can do about this.  Armin suggested another hack:
stick the address of a stack variable in Py_Main() in a global and
compare the address of another stack variable when you want to see how
much stack you have left.  Obvious problems include knowing what's
safe and which direction the stack is growing in... Even more scarily,
what SBCL (a Common Lisp implementation) does is mprotect() a VM page
and the end of the stack and deal with overflow in a SIGSEGV handler.
It's hard to see what else could be really safe (have I mentioned that
I hate C recently?).

Option 3, I guess, is integrate stackless :-)

Cheers,
mwh

-- 
8. A programming language is low level when its programs require
   attention to the irrelevant.
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html



More information about the Python-Dev mailing list