Inconsistent Behavior on Failed Run

[wknowleskellett]

from this issue in rhaiscript/rhai

Issue: Code runs fine in the playground. Make a breaking change and the code fails. Put the code back to the working version and it no longer works.

Steps to reproduce:

1. Open primes.rhai in the playground
2. Set const MAX_NUMBER_TO_CHECK = 100_000_000;
3. Run it (success. for me, 83 seconds)
4. Set const MAX_NUMBER_TO_CHECK = 1_000_000_000;
5. EXCEPTION: RuntimeError: unreachable executed
6. Change it back: const MAX_NUMBER_TO_CHECK = 100_000_000;
7. EXCEPTION: Error: recursive use of an object detected which would lead to unsafe aliasing in rust

So somewhere in the playground, something breaks and fails to clean itself before the next run.

[alvinhochun]

This appears to be caused by a panic from std::Vec, presumably from prime_mask.pad(MAX_NUMBER_TO_CHECK + 1, true); (makes sense since Wasm32 is 32-bit.) Since the panic causes Rust to abort, I guess one is not supposed to call back into Rust from that point onward. It probably also messes up some internal states of wasm-bindgen. Not sure what should/could be done about it from the playground side, since it is completely different from something like a syntax error.

One may consider catch_unwind, but does wasm-bindgen even support unwinding? (Sorry I am a bit out of the loop with the state of Rust and Wasm.) Even if it's supported, enabling panic=unwind would probably bloat the binary size by a lot.

What if we catch it from JS? Well I mean we already do, that's why the exception is appended to the output. But what else can it do? I think there's not much doable other than to add a note to instruct the user to reload the page.

[schungx]

Maybe we need to restrict the max array length? Or max map size?

But since this is a playground, if it crashes due to out-of-memory then should not be a big deal...

Problem is to be able to catch the panic...