1

I wrote a trivial AssemblyScript function:

export function F(s: string): i32 {
    return s.length;
}

Loading and using the resulting F.wasm in the browser WORKS WELL while I got RuntimeError: memory access out of bounds using Node.js (on Windows, v18.12.1). Here is my Node.js code:

const imported_object = {env: {abort: (a, b, c, d) => console.log(a)}};
WebAssembly.instantiate(fs.readFileSync("./build/F.wasm"), imported_object).then(module => {
    const {F} = module.instance.exports;
    console.log(F("4719512002889")); // Output: '13' in the browser
});

Note 1: on macOS, the error is Bus error 10, which is weird? (same Node.js ver. is used, ie, v18.12.1)

Note 2: it was mandatory to set up and pass imported_object to avoid other errors (see also WebAssembly: TypeError: WebAssembly Instantiation: Imports argument must be present). I however feel that imported_object isn't well configured?

Note 3: I've tried the AssemblyScript compiler with several "memory" options but the lack of explicit clear doc. on such compiler parameters does not allow me to fix my problem.

Help appreciated... Thanks in advance.

TachyonicBytes
  • 700
  • 1
  • 8
Bab64
  • 99
  • 8
  • In fact, AssemblyScript compiler **ALSO** generates JavaScript file, say `F.js`, ( **based on ES module technology**). The file directly uses the WebAssembly JavaScript API. Using this file (both for the browser or Node.js) is safer: this avoids "risky" homemade code as mine (ie, `WebAssembly.instantiate...`). Unfortunately, if I still uses the WebAssembly JavaScript API, the runtime memory error comes from `imported_object`. Calling `instantiate` with this argument raises an error: 2nd argument, ie `imported_object`, is mandatory. So, `imported_object` is the source of the problem. – Bab64 Dec 05 '22 at 10:59
  • Highlights here: https://www.assemblyscript.org/concepts.html#special-imports and https://www.assemblyscript.org/concepts.html#accessing-memory-during-instantiation. – Bab64 Dec 06 '22 at 07:42
  • What does your `asconfig.json` say at the `options.bindings`? Is it `"esm"` or `"raw"`? If it's `"esm"` then you are expected to import the `F` function to JS side like `import * as SomeNameSpace from "../build/release.js"` and invoke it like `SomeNameSpace.F()`. `release.js` does all bindings automatically. If you would like to instantiate it manually and have more control then the `options.bindings` shoul be `"raw"`. In this case you only import the `instantiate` function from `release.js`. Check [here](https://www.assemblyscript.org/compiler.html#using-raw-bindings). – Redu Dec 06 '22 at 12:02
  • Many thanks. I've solved all of my problems but, sorry about that, my question comes from a "dude" in WebAssembly. Pratically, `bindings` set to `ESM` does the job, ie, AssemblyScript generates `F.js`. So, import it (browser or Node.js) as a ES module, all works fine for me both client and server sides... – Bab64 Dec 06 '22 at 13:23

0 Answers0