rust_lisp icon indicating copy to clipboard operation
rust_lisp copied to clipboard

Stackoverflow not caught by the interpreter

Open chebureki opened this issue 2 years ago • 2 comments

A stack overflow is not caught by the interpreter => boom crash panic Example:

; + operator just so no tailcall optimization will help out
(defun overflow () (+ 1 (overflow)))
(overflow)

Optimally, the interpreter will return an error. You could add a depth value to the Env struct. If you try to enter a new env, and the new depth exceeds a maximum stack height, it will return an error

chebureki avatar Mar 24 '23 20:03 chebureki

Hmm. I'm wondering how a maximum depth would be chosen for the interpreter

I could pick an arbitrary ~reasonable maximum number, but that might be lower than necessary (or too large, where Rust runs out of memory anyway!)

I could try and base it on Rust's stack size (in bytes), but the main thread's stack size varies by the OS. You can spawn a separate thread with a specific stack size, but that gets into more complex waters. And I'd have to calculate or estimate the stack size of the actual Rust function to divide it by

The ideal solution would be to catch the stack overflow error and then handle it gracefully, but I don't think Rust exposes a way to do that

The only other thing I can think of is letting the user pass an (optional) max depth to eval when it's called

Thoughts on all that?

brundonsmith avatar Mar 25 '23 02:03 brundonsmith

I think a hard-coded/user-specified number will do the job just fine That's what python does:

import sys
sys.setrecursionlimit(1500)

One, perhaps less important, thing to consider: you should theoretically also consider the depth of the eval calls.

If you had deeply nested expressions, they would also use up the stack. A stack overflow could still occur for deeply nested code. But honestly, this has little importance. It should only happen, if you intentionally do it.

chebureki avatar Mar 25 '23 09:03 chebureki