Re: [Sbcl-devel] stack exhaustion

[William H. N. <wil...@ai...>]

On Mon, Mar 18, 2002 at 02:44:58PM +0000, Daniel Barlow wrote:
> I just had a quick squint at the code for checking control stack
> exhaustion (the PPC port had only 400k or so allocated for control
> stack, so it brought itself to my attention fairly early in cold init
> ;-)
> 
> I wonder if it would be possible/sensible to implement a control stack
> guard zone using mprotect() in much the same way as we do for dynamic
> space: this would mean there's no slowdown in normal use, so we could
> handle stack exhaustion gracefully at all safety levels.  Thoughts?

The only reason I didn't do it this way was that I was afraid it would
be harder, since I expect the required signals code would be trickier
than the current code. In this case the trickier version would be so
much more efficient that pointing out the trickiness isn't a criticism
-- I'd be happy to merge such code -- just an admission of laziness,
in that I just wasn't motivated to write it myself.
 
The current stack safety code is, in Gabriel's terms, more or less the
New Jersey approach. It was easy to write, and it works[*][**], and it
gets me a long way toward what I want from where I was without it, and
I think it should be easy to understand and maintain. In this it
resembles the patch I submitted to clocc/ansi-test which gave a bug id
to each failure report so that we could use it for regression tests in
SBCL before we fix every last bug. Someone (Sam, I think) pointed out
that the ansi-test fixes really didn't do everything one might ideally
want. Someone else (PVE, I think) responded, as I might have, that the
code had sat for years without any progress being made on the
ambitious approach, so that maybe the best thing was to accept the
easy fix which did enough to be useful instead of waiting years longer
for someone to do the more ambitious thing. I justify the current
stack safety code the same way.

[*] Actually, in my BUGS file, not checked in yet, I have
  There's some sort of problem with aborting back out of the debugger
  after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
  telling the debugger to ABORT doesn't get you back to the main REPL,
  but instead just gives you another stack exhaustion error. The problem
  doesn't occur in the trivial case
    * (defun frob () (frob) (frob))
    FROB
    * (frob)
  but it has happened in more complicated cases (which I haven't
  figured out how to reproduce).
It might be that this has to do with things like UNWIND-PROTECT
which can be executed as the stack is being unwound.

[**] Also, I think %DETECT-STACK-EXHAUSTION calls may be being
compiled into SBCL's own code more often than I intended. I intended
to have them called in only a few places, or maybe none, in SBCL
itself, and have them only compiled in safe user code. I need to
review the compilation options used in building SBCL and understand
what's really happening. Having %DETECT-STACK-EXHAUSTION compiled into
too much code for a few CVS versions should be tolerable (or even
arguably a good thing because it will test it more aggressively:-) but
hopefully before quasifreezing code for 0.7.2 I can tone it down a
little.

-- 
William Harold Newman <wil...@ai...>
"Of course, if I dig my house foundations by biting the earth while banging
my own head with a spade, then upgrading to mechanical digger maybe won't
help..." -- Graham Perkins <gpe...@dm...> in comp.lang.eiffel
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C