Hmm, I see what you mean:
Code: Select all
[3]> (defun tato () (tato))
TATO
[4]> (tato)
*** - Program stack overflow. RESET
Clisp
does have a debugger, but for program stack overflow it doesn't use it, and just resets.
Infinite recursion is a sticky case, in general, for programs to recover from.
The stack...
- contains all of the local variables for each function in the current thread of execution.
- is allocated when a thread is created, with a particular size,
- cannot be re-sized at run-time, because heap memory might have been allocated next to the stack,
- cannot be re-located either, because you would need to re-write any pointers to stack locations (which is impossible to do correctly).
The result of this is that when you run out of stack you can't invoke any functions that need local variables (because that would push you even further into danger territory). Some systems keep a chunk of memory aside (in the heap) to store the temporary variables it might need in the event of such a problem, but clisp, apparently, doesn't do that.
Depending on your code you may be able to track the infinite recursion by using TRACE on your suspect function, alternatively you can use one of the clisp methods for starting with an increased stack size (if you don't have infinite recursion, just very deep function calls).
http://www.clisp.org/impnotes.html#faq-stack