Eli Zaretskii wrote:
> The implementation of stack_overflow on sysdep.c was recently changed
> so as not to use sys/resource.h and getrlimit, but configure.ac still
> insists on these two features in order to include the recovery code,
> which I think should be fixed.

Thanks, fixed with the attached patch.

> More importantly, the recovery simply longjmps to command_loop,
> whereas similar features like Fthrow and Fsignal do much more in
> unwind_to_catch.  Shouldn't stack overflow recovery do that as well?
> Otherwise, the specpdl stack, byte_stack_list, lisp_eval_depth
> etc. all stay at their values they had at stack overflow time, no?

No, they are cleared back to top-level values, because when command_loop's call 
to sigsetjmp returns nonzero, it then calls init_eval and this resets them.

There is a problem that the speclpdl stack's unwind-protect and 
dynamic-let-bindings are unceremoniously discarded on stack overflow.  I suppose 
that should get fixed, though it may be a bit tricky to avoid looping.