Generated binary crashes with "RuntimeError: memory access out of bounds"

[womeier]

Description

The wasm-bindgen build command succeeds, but the generated binary crashes with RuntimeError: memory access out of bounds.
main.rs is generated by the https://github.com/AU-COBRA/coq-rust-extraction plugin, it could be a bug there as well. I suspect it's in wasm-bindgen, because the setup works with a standard rust setup.

Working setup without wasm-bindgen

sm_gauss_nat-working.zip

cargo run in the attached project works, it prints the expected result Some(O(PhantomData<&()>)).
(The source program takes an arithmetic expression representing the sum of 1 to n, compiles it to a toy stack-machine
and executes it, then subtracts n*(n+1)/2 from the result, so the expected value is 0.)

Steps to Reproduce

sm_gauss_nat-crashing.zip

In the attached project, the main file is exactly the same as in the working one above,
except for the lines at the bottom related to wasm-bindgen.

1. wasm-pack build --target nodejs
2. in pkg/sm_gauss_nat.js: replace write_string with console.log and add wasm.main() at the bottom
3. then run with nodejs: node --stack-size=1000000 sm_gauss_nat.js
4. Fails with the following error

Error

wolfgang@laptop:~/sm_gauss_nat-extracted/pkg$ node --stack-size=1000000 sm_gauss_nat.js 
wasm://wasm/0005b416:1

RuntimeError: memory access out of bounds
    at wasm://wasm/0005b416:wasm-function[22]:0x3b74
    at wasm://wasm/0005b416:wasm-function[22]:0x3b3d
    at wasm://wasm/0005b416:wasm-function[22]:0x3b5f
    at wasm://wasm/0005b416:wasm-function[22]:0x3b3d
    at wasm://wasm/0005b416:wasm-function[22]:0x3b5f
    at wasm://wasm/0005b416:wasm-function[22]:0x3b3d
    at wasm://wasm/0005b416:wasm-function[22]:0x3b5f
    at wasm://wasm/0005b416:wasm-function[22]:0x3b3d
    at wasm://wasm/0005b416:wasm-function[22]:0x3b5f
    at wasm://wasm/0005b416:wasm-function[22]:0x3b3d

Node.js v20.11.1

Possibly relevant

The main.rs is generated by a compiler, and the setup with the wasm-bindgen macros works as expected on a few other programs. We have some other Wasm binaries here, which one can run with included Node.js based run script,
I can provide more source code for the working examples in case it helps.

Thanks!

[daxpedda]

3. then run with nodejs: node --stack-size=1000000 sm_gauss_nat.js

Didn't look at anything closely, but this did jump out to me.
I'm not familiar with Node, but I believe this only increases the JS stack size, if you want to increase the WebAssembly stack size you have to use -Clink-arg=-zstack-size=1000000 (not sure exactly how page size plays a role here?).

[womeier]

Hi @daxpedda. Thanks for the response!

Just tried the following, but it still crashes with the same error.

$ export CARGO_BUILD_RUSTFLAGS="-Clink-arg=-zstack-size=1000000"
$ wasm-pack build --target nodejs

then steps 2,3,4 as above.

Is that what you meant?

FYI: I use node with the --stack-size flag, so the call stack doesn't overflow. (the Wasm binary has a lot of function calls)
I'd be surprised if this is related to the crash.

If I had to guess, I'd say it's due to the rust library bumpalo and wasm-bindgen generating ill-formed code for that somehow.

https://docs.rs/bumpalo/latest/bumpalo/

[daxpedda]

Is that what you meant?

Indeed.
Though I usually use RUSTFLAGS directly, so I hope CARGO_BUILD_RUSTFLAGS doesn't have weird interactions with wasm-pack.

If I had to guess, I'd say it's due to the rust library bumpalo and wasm-bindgen generating ill-formed code for that somehow.

Ill-formed code? This is usually in the context of code generation which only wasm-bindgen does very minimally, the codegen happens in Rustc/LLVM. Or what am I missing here?

---

On that note, did you try running it in release mode?
Rustc/LLVM can sometimes create some pretty terrible Wasm which might affect your stack size.

Considering that I won't have the leisure time to debug this, all I can offer here is help you debug this.
The way I would usually start is by looking at the stack trace and identify which instruction ultimately caused the issue and extrapolate from there.
I know debugging in Wasm is usually a terrible experience, so let me know where you are stuck and I might be able to help.

[womeier]

I'm fairly certain that the memory access out of bounds refers to an out-of-bounds read/write in Wasm's linear memory.
So if wasm-bindgen doesn't generate Wasm code itself, then this is perhaps the wrong place and I should report it somewhere else.

[daxpedda]

I'm fairly certain that the memory access out of bounds refers to an out-of-bounds read/write in Wasm's linear memory.

Indeed.
I was just going with the theory here that it might be an issue with the stack size, which does affect the available Wasm linear memory.
But, as I said, I didn't actually look into your application.

So if wasm-bindgen doesn't generate Wasm code itself, then this is perhaps the wrong place and I should report it somewhere else.

I was talking specifically about "codegen", ergo the Wasm output, which indeed the majority of doesn't happen in wasm-bindgen.
But this error could still be caused by wasm-bindgen, which might be doing some wrong things here or there.

However, looking briefly into your application, I don't see you use anything actually wasm-bindgen related, except this part:

#[wasm_bindgen]
extern "C" {
  fn write_string(s: &str);
}

So unless the error happens here, its very unlikely this is wasm-bindgen related (unless it happens somewhere in your dependencies, which I didn't look at).