[Ecls-list] [Maxima] segmentation fault with Maxima/ECL

[Geo Carncross]

On Thu, Sep 25, 2008 at 11:07 PM, Gabriel Dos Reis
<gdr at integrable-solutions.net> wrote:
>> Something often overlooked is that setrlimit() can set the stack size.
>> Simply set RLIMIT_STACK to (RLIM_INFINITY) unlimited and Linux (and
>> most other systems) will grow it as necessary - at least until it
>> collides with the heap.
>
> However, some users would prefer a SIGSEGV to an ever growing stack.
> Quite frankly, I think ECL shouldn't try that.  It should be left to the user.

Agreed. That's why RLIMIT_STACK is usually set in the first place:
Extremely deep stacks are normally a sign of a buggy program, and not
the sign that they need to be increased.

>> However, another possibility is to hook up SIGSEGV as a CL condition,
>> and simply give it an alternate (static) stack with sigaltstack()
>
> SBCL reports stack exhaustion without trying to automatically growing it.

This is the mode I liked best as well.

I'd be happy to write a unix implementation, but I don't believe
Windows has a sigaltstack() that works.

The Windows method (I believe) should look something like this:

 SetUnhandledExceptionFilter(fun);
...
 long __stdcall fun(struct _EXCEPTION_POINTERS *ep)
 {
    if (ep->ExceptionRecord->ExceptionCode == STATUS_STACK_OVERFLOW) {
        ... do something ...
    }
     return EXCEPTION_CONTINUE_SEARCH;
 }

However, I think that the amount of stack reserved for "do something"
is likely very small, and I don't know how to switch stacks on Windows
correctly.

I know that a fiber can be used to preallocate a coroutine (and stack)
that could contain the condition loop, but I'm vaguely aware that
there are problems mixing fibers with threads, blocking IO, and other
things that might lurk in ECL on Windows systems. I furthermore have
no way to test such a beast.