On Tue, 7 Jun 2005, [ISO-2022-JP] =CB=DC=B4=D6 =C2=E7=CA=E5 wrote:
> The worst case I think is that this code causes segmentation fault.
> (defun fact (x) (if (zerop x) 1 (* x (fact (1- x)))))
> (fact 100000)
SBCL has two guard pages at the "top" of the stack, one of which should be=
protected at any time:
* Touching the "lower" one should result in the "upper" being
protected, and the "lower" one unprotected.
* Touching the "upper" one should result in the "lower" being
protected, "upper" being protected, and a CONTROL-STACK-EXHAUSTED-ERROR
condition being signalled via arrange_return_to_lisp_function.
(The purpose of this see-saw action is to ensure that the top of
the stack is unprotected only when handling the
To debug this I would add printfs to handle_guard_page_triggered, to
see where things go awary -- and if indeed we even get as far as there.
At a guess the most likely culprit is arrange_return_to_lisp_function.
(The actual order of the guard pages depends on the direction of the=20
stack, but the "lower" one is called CONTROL_STACK_RETURN_GUARD_PAGE, and=
the "upper" one CONTROL_STACK_GUARD_PAGE.)
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."