Failures when decoding the input cause a memory leak.

[utdemir]

When tsify fails to parse the argument passed, it throws an error which causes a memory leak on Rust side. Which eventually causes a memory access out of bounds to be thrown, irrecoverably killing the WASM instance.

Reproducer here: https://github.com/utdemir/tsify-leak-repro

I dug in a bit and here's what I think happens: #[tsify(from_wasm_abi)] generates a FromWasmABI implementation which uses throw_str when parsing fails. Which has a note in docs:

Note that it is very easy to leak memory with this function because this function, unlike panic! on other platforms, will not run destructors. It’s recommended to return a Result where possible to avoid the worry of leaks.

From a cursory look - I don't think FromWasmABI is meant to be used with fallible conversions. So unsure what the proper fix would be other than significantly changing the tsify interface. Or coordinating with wasm_bindgen folks to allow partial FromWasmABI implementations.

[siefkenj]

Good find. What would happen if instead of using wasm_bindgen::throw_str(err.to_string().as_ref()); we propagated the Err to the caller? I presume that throws a JS error but with a confusing error message?

[madonoharu]

This issue also seems to be related:
#47

[madonoharu]

Ts<T> is released in 0.5.7, which is the fix for this. Your analysis holds exactly as written: FromWasmAbi::from_abi returns Self, so the generated impl has nowhere to report a serde failure except wasm_bindgen::throw_str, and that skips destructors.

What I want to record here, since this is the issue the deprecation message points at:

The attributes cannot be fixed in place. FromWasmAbi, RefFromWasmAbi, LongRefFromWasmAbi and VectorFromWasmAbi all return Self rather than a Result, and TryFromJsValue is not used for exported-function arguments, so there is no fallible path available at the ABI boundary. I couldn't find an upstream issue or proposal to change that either. Ts<T> works by keeping the boundary infallible — it is #[repr(transparent)] over the JS handle and only forwards it — so deserialization happens in the function body where it is an ordinary Result and a normal return runs destructors.

#[wasm_bindgen]
pub fn from_js(point: Ts<Point>) -> Result<(), JsError> {
    let point: Point = point.to_rust()?;
    Ok(())
}

into_wasm_abi has the same root cause but panics instead of leaking, so it fails loudly rather than silently.

Leaving this open as the tracking issue for the deprecation: the attributes still work, nothing is scheduled for removal, and the migration is documented rather than forced. #47 and #86 are closed as the same root cause, with #86's separate ergonomics request split out to #93.