> To me it looks as though getrlimit(RLIMIT_STACK, ...) will return the size
> of the maximum stack, not an address. How do you get the actual size of the
> current stack in a stack check? What is rlimit_stack here, and how do you
> get hold of it?
It's easy enough to get the (approximate) address of the stack
pointer: just take the address of a variable allocated in the current
stack frame. Then add (for downward growing stacks) a conservative
estimate of the current stack size (e.g., 8k on entry to main) to give
the start address of the stack. Now subtract the maximum stack size
and, hey presto, you have the address of the stack limit.
> > If it triggers, throw an exception that the programmer
> > can catch in the IO monad. (See code for throwing pattern match
> > exceptions for comparision.)
>
> The problem is though that the situation is critical when the stack is low,
> so having an exception might not make sense. But one could offer the
> possibility of trying to reset the stack limit, and if that fails, the
> ability to start a new program.
So the (C) code that catches an exception (i.e., the setjmp) should
check for stack overflow and, if that fails, rethrow the stack
overflow exception (which makes the C stack smaller, of course).
Eventually (in fact, rather quickly), you'll find an exception handler
that is safely below the stack overflow limit. (There is always one
exception handler in place during evaluation and if there's not enough
stack space for that, then Hugs just won't work at all.)
(If we were talking about heap overflow, then the situation would be
different because just because I drop some pointers into the heap
doesn't guarantee that more space becomes available.)
Of course, the programmer might have written an infinite loop using
exception handling:
catch big (\ _ -> 1 + big)
but we can already deal with infinite loops by hitting ctrl-C (or whatever).
As long as that works (and I see no reason it shouldn't) we're cool.
A
