bytecodealliance/jco

Strict trap handling

Opened this issue · 2 comments

guybedford commented

We should be stricter about traps in jco.

When a component traps it moves into a trapped state and is no longer callable, so this should be a flagged state of the component.

All call validation errors should also be traps as well, trickling up and setting the trapped flag on call calling components.

In the case or exported function validation errors, these do not need to trap as they happen before entering the component.

guybedford commented

Here's my best shot at formal trap semantics:

  • We make WebAssembly.RuntimeError the formal trap error, and update all bindgen-level validation functions to throw WebAssembly.RuntimeError as opposed to generic Error, TypeError or RangeError.
  • When calling an imported function that does not return a result, any error is treated as a trap, and we rewrap that error in a WebAssembly.RuntimeError if it is not already a WebAssembly.RuntimeError (possibly with a cause property pointing to the original JS error).
  • If calling an imported function that returns a result, we strictly verify that the error is not an instance of WebAssembly.RuntimeError. If it is, then we rethrow the runtime error as a trap error.
  • At all places we detect a runtime error, we immediately mark the component as trapped, similarly to the mayenter state, which should also be checked on all calls already.
  • All WASI errors that are traps in the JS implementation should be thrown as WebAssembly.RuntimeError as well.

Even if we don't get to the full trap handling right now, at the very least we can start to formalize WebAssembly.RuntimeError checks as the primary mechanism where traps are being initiated and caught already currently.

guybedford commented

For now, all errors are now TypeError and we added stricter error coercion in the most recent release where only result<_, string> is permitted to coerce JS errors for called functions.

We should still ensure that all type validations are traps though (TypeError at the very least), and working towards that being comprehensively done is an ongoing concern.