|
From: | Paul Eggert |
Subject: | Re: Two issues with stack overflow protection |
Date: | Tue, 28 Jul 2015 22:01:55 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 |
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.
0001-Remove-unnecessary-stack-overflow-dependency.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |