SpiderMonkey uses recursive algorithms in quite a few places. As the
level of recursion is at mercy of JS code, checking for stack
exhaustion is a must. For that the code explicitly compare an address
of a local variable with a limit set as a part of thread
initialization. If the limit is breached, the code either reports
failure to the caller (parser, interpreter, JITed code) or tries to
recover using a different algorithm (marking phase of GC).
This explicit strategy allowed to archive stack safety with relatively
infrequent stack checks compared with the total number of function
calls in the code. Granted, without statick analysis this is fragile
as missing stack check on a code path that is under control of JS
could be potentially exploitable (this is C++ code after all), but it
has being working.
So I think aborting on stack overflow in Rust should be OK as it
removes security implications from a stack overflow bugs. However, it
is a must then to provide facilities to check for a low stack. It
would also be very useful to have an option to call code with a newly
allocated stack of the given size without creating any extra thread
etc. This would allow for a pattern like:
fn part_of_recursive_parser ... {
if stack_low() {
call_with_new_stack(10*1024*1024, part_of_recursive_parser)
}
}
Then missing stack_low() becomes just a bug without security implications.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
