Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eagerly cached TypedArray objects cause circular dependency for bundler modes #2961

Closed
ishitatsuyuki opened this issue Jun 22, 2022 · 1 comment · Fixed by #2965
Closed
Labels

Comments

@ishitatsuyuki
Copy link
Contributor

Describe the Bug

Descriptions like cachedInt32Memory0 = new Int32Array(wasm.memory.buffer); creates a circular dependency between the bg module and the instantiation wrapper created by bundlers, because the wrapper needs to import the bg module to pass the exports to WebAssembly.instantiate's second argument (importObject), while this depends on wasm.memory which is initialized after the instantiation is complete.

Steps to Reproduce

I haven't isolated the reproduction yet, because it seems to depend on the use of certain ArrayBuffer related function calls.

I'm using https://github.com/Menci/vite-plugin-wasm, but at a quick glance Webpack should be doing the implementation in basically the same manner.

Errors

Uncaught ReferenceError: can't access lexical declaration 'memory' before initialization
    <anonymous> http://localhost:3000/rust/pkg/wasm_bg.js?t=1655889863398:318

Proposed modification

Just make it lazy.

diff --git a/crates/cli-support/src/js/mod.rs b/crates/cli-support/src/js/mod.rs
index 8ca6a854..86dda79c 100644
--- a/crates/cli-support/src/js/mod.rs
+++ b/crates/cli-support/src/js/mod.rs
@@ -607,10 +607,9 @@ impl<'a> Context<'a> {
             for kind in views {
                 writeln!(
                     out,
-                    "cached{kind}Memory{num} = new {kind}Array(wasm.{mem}.buffer);",
+                    "cached{kind}Memory{num} = new {kind}Array();",
                     kind = kind,
                     num = num,
-                    mem = mem,
                 )
                 .unwrap()
             }
Liamolucko added a commit to Liamolucko/wasm-bindgen that referenced this issue Jun 27, 2022
In the bundler target, there's a circular dependency between the bindings and the wasm module. That means that the wasm module's exports aren't available at the top level. In rustwasm#2886, I didn't realise that and made the memory views be initialised at the top level, which resulted in an error from the wasm module's memory not being available yet.

This fixes that by lazily initialising the memory views like they were before rustwasm#2886, except that they're reset to uninitialised in `init` to make sure they're updated if it's called multiple times (the reason I made them be immediately initialised in the first place).
ranile pushed a commit that referenced this issue Jun 27, 2022
In the bundler target, there's a circular dependency between the bindings and the wasm module. That means that the wasm module's exports aren't available at the top level. In #2886, I didn't realise that and made the memory views be initialised at the top level, which resulted in an error from the wasm module's memory not being available yet.

This fixes that by lazily initialising the memory views like they were before #2886, except that they're reset to uninitialised in `init` to make sure they're updated if it's called multiple times (the reason I made them be immediately initialised in the first place).
@gthb
Copy link
Contributor

gthb commented Jul 23, 2022

In my case (running in Node.js 16, importing the wasm-bindgen module as an ES module, having run wasm-pack with --target bundler and changed the generated package.json to have "type": "module" and a "main" attribute), the problem manifested as:

ReferenceError: memory is not defined

(just adding that comment to make this issue easier for others to find than it was for me! 😊)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
2 participants