wasm-bindgen introduces potential panics into code

[newpavlov]

Let's say I have a crate with the following Cargo.toml and src/lib.rs:

[package]
name = "foo"
version = "0.1.0"
edition = "2021"

[lib]
name = "foo"
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = { version = "0.2.89", default-features = false }

[profile.release]
panic = "abort"

#[no_mangle]
pub extern "C" fn add(a: u32, b: u32) -> u32 {
    a.wrapping_add(b)
}

Compiling it results in a small and compact WASM file as expected.

But trying to use wasm-bindgen, even without doing anything with it:

use wasm_bindgen::prelude::wasm_bindgen;

#[no_mangle]
pub extern "C" fn add(a: u32, b: u32) -> u32 {
    a.wrapping_add(b)
}

#[wasm_bindgen]
extern "C" {}

results in a much bigger file, which includes allocator and potential panic paths. This not only bloats size of generated WASM files, but also makes it harder to write robust code which attempts to "prove" that it does not contain any potential panics.

Is this behavior intended and expected?

[daxpedda]

[profile.release]
panic = "abort"

This is the default on wasm32-unknown-unknown btw.

results in a much bigger file, which includes allocator and potential panic paths. This not only bloats size of generated WASM files, but also makes it harder to write robust code which attempts to "prove" that it does not contain any potential panics.

I'm going to assume that you have done the post-processing with the CLI here.

The only difference I can see is a data segment, that is unreferenced.
The data segment doesn't do anything, it just holds a bunch of unused strings that as you say bloat the resulting Wasm module.

wasm-bindgen works by inserting functions into the module, which are executed by the post-processor, extracting the necessary information, and then removed afterwards. These functions contain panicking code, which generate these strings. Unfortunately, while removing these functions, the post-processor is unable to detect the corresponding strings and remove them.

I'm not aware of any way to remove these parts of the data segment reliably and correctly. What could be done is to avoid any panicking code in these "synthetic" functions (e.g. here), but unfortunately this requires unchecked indexing into arrays and slices, which Rust doesn't support.

---

That said, it should be quite easy to verify that the code generated by your example can't panic:

(module
  (type $type0 (func (param i32 i32) (result i32)))
  (memory $memory0 17)
  (export "memory" (memory $memory0))
  (export "add" (func $func0))
  (func $func0 (param $var0 i32) (param $var1 i32) (result i32)
    local.get $var0
    local.get $var1
    i32.add
  )
  (data (i32.const 1048576) "/rust/deps/dlmalloc-0.2.6/src/dlmalloc.rsassertion failed: psize >= size + min_overhead\00\00\00\10\00)\00\00\00\a8\04\00\00\09\00\00\00assertion failed: psize <= size + max_overhead\00\00\00\00\10\00)\00\00\00\ae\04\00\00\0d")
)

As you can see, no unreachable instruction.
I wouldn't look at the data segment to determine if the code can panic during runtime anyway, there could be unreachable instructions without any attached string in the data segment.

[newpavlov]

What could be done is to avoid any panicking code in these "synthetic" functions (e.g. here), but unfortunately this requires unchecked indexing into arrays and slices, which Rust doesn't support.

Assuming enabled optimizations, the flat_len function is always panic-free. flat_byte_slices is a bit more complex since it can panic if input slices are too big (i.e. it's impossible to eliminate panics locally). You could return Option<[u8; RESULT_LEN]>, but whether it's practical or not depends on how the function is used. I agree that properly eliminating potential panics can be quite hard, but it would be nice for it to get a bit of attention, since it may be possible to do with some code refactoring.

it should be quite easy to verify that the code generated by your example can't panic

The original code is much less trivial than this minimal reproduction example. I could write a static analyzer of WAT for checking whether function's call tree contains unreachable instructions, but it's not a trivial undertaking.

[daxpedda]

I think there is a misunderstanding here: wasm-bindgen ultimately removes this function and any panics connected to it, the data section doesn't contain any instructions in general, so there aren't any "leftover" panics that aren't cleaned up or anything like that.

The resulting module does not contain an allocator or potential panic paths, as you thought in the OP.

The original code is much less trivial than this minimal reproduction example.

Please let me know if there are any actual panics or unreachable instructions inserted by wasm-bindgen that were actually unable to be removed by the post processor.

I could write a static analyzer of WAT for checking whether function's call tree contains unreachable instructions, but it's not a trivial undertaking.

Is there some other way to check?

But for clarity: checking for the word "unreachable" in your WAT is more then enough, this doesn't require a static analyzer.

I agree that properly eliminating potential panics can be quite hard, but it would be nice for it to get a bit of attention, since it may be possible to do with some code refactoring.

While I don't think the panics are a concern, because they get removed, the data section is an unfortunate byproduct.

I'm happy to get any suggestions or review a PR!

[newpavlov]

Ah, I was looking at wasm file generated by cargo build --release --target=wasm32-unknown-unknown (you hinted about it in the first message, but I haven't noticed it). Running it through wasm-bindgen-cli indeed eliminates panics and allocator from the resulting wasm file. The redundant data section is unfortunate, but it's not important in my case.