Re: SEGV on bad recursion

[Ilya Zakharevich <ilya@math.ohio-state.edu>]

Gerhard Niklasch writes:
> (4) On SunOS/Solaris where Igor originally observed this behavior,
> the C stack sits in a fixed-size (8MBy) memory segment, and fills up
> this segment before the parameter blocks exhaust the default PARI stack,
> and before the other allocations exhaust the available virtual memory.

Type 
     limit
on your shell command-line.

> (6) However, the signal handler is now faced with an already overflowing
> C stack, and cannot allocate its own stack frame, so the whole affair
> dumps core.  (Actually, the kernel probably notices this before returning
> control to the gp process at user level, and initiates the core dump at
> once.)
> 
> The behavior varies a bit depending on the operating system.  Under Linux,
> there's no hard limit at 8MBy, 

Neither is on Solaris.

> There doesn't appear to be a reliable and portable way to catch the
> problem just before we are beyond recovery.

On OS/2 you do it like this: you put a "guard" page at the end of the
stack (it may be easily found), when this page is touched, you get a
different kind of "signal" (exception, in IBM-speak), which is
catchable (since exceptions are processed on a separate stack?).

Generally speaking, there should be a way to request a separate stack
for a given C function.

Ilya