memory access out of bounds

[ivnsch]

Describe the Bug

When calling an async function that makes a reqwest call, there's a "memory access out of bounds" error. This seems to be specific to web target / next.js configuration.

Steps to Reproduce

1. Checkout https://github.com/ivanschuetz/nextjs-wasm-error/tree/error (error branch)
2. Run project, as explained in the readme.
3. See error on the browser's console.

Expected Behavior

The page shows "Computed from WASM: 4+3=7" text and there are no errors on the console.

Actual Behavior

The page shows "Computed from WASM: 4+3=undefined" text and there's a "memory access out of bounds" on the console.

Additional Context

The error project is based on a working template (https://github.com/satelllte/nextjs-wasm). The changes in the error project are making the WASM function async and using reqwest.

Error:

wasm_bg.9a1a93a1.wasm:0x3107c Uncaught (in promise) RuntimeError: memory access out of bounds
    at wasm_bg.9a1a93a1.wasm:0x3107c
    at wasm_bg.9a1a93a1.wasm:0x326b5
    at __wbg_adapter_26 (wasm.js?1f94:208:10)
    at real (wasm.js?1f94:193:20)
$func397 @ wasm_bg.9a1a93a1.wasm:0x3107c
$_dyn_core__ops__function__FnMut__A____Output___R_as_wasm_bindgen__closure__WasmClosure___describe__invoke__h3da3ba1ec5f8b58d @ wasm_bg.9a1a93a1.wasm:0x326b5
__wbg_adapter_26 @ wasm.js?1f94:208
real @ wasm.js?1f94:193
Promise.then (async)
imports.wbg.__wbg_then_e5489f796341454b @ wasm.js?1f94:432
$func129 @ wasm_bg.9a1a93a1.wasm:0x21d61
$func48 @ wasm_bg.9a1a93a1.wasm:0x5eb1
$func254 @ wasm_bg.9a1a93a1.wasm:0x2c95f
$func161 @ wasm_bg.9a1a93a1.wasm:0x25d0b
$_dyn_core__ops__function__FnMut__A____Output___R_as_wasm_bindgen__closure__WasmClosure___describe__invoke__h3da3ba1ec5f8b58d @ wasm_bg.9a1a93a1.wasm:0x326b5
__wbg_adapter_26 @ wasm.js?1f94:208
real @ wasm.js?1f94:193
Promise.then (async)
imports.wbg.__wbg_then_18da6e5453572fc8 @ wasm.js?1f94:428
$func229 @ wasm_bg.9a1a93a1.wasm:0x2b3f6
$func327 @ wasm_bg.9a1a93a1.wasm:0x2f76e
$func278 @ wasm_bg.9a1a93a1.wasm:0x2dbf2
$wasm_bindgen__convert__closures__invoke2_mut__h772fbf3027cc45cc @ wasm_bg.9a1a93a1.wasm:0x325f5
__wbg_adapter_64 @ wasm.js?1f94:229
cb0 @ wasm.js?1f94:412
imports.wbg.__wbg_new_52205195aa880fc2 @ wasm.js?1f94:417
$add @ wasm_bg.9a1a93a1.wasm:0x30b89
add @ wasm.js?1f94:217
_callee$ @ WASMExample.tsx?bc08:12
tryCatch @ runtime.js?ecd4:45
invoke @ runtime.js?ecd4:274
prototype.<computed> @ runtime.js?ecd4:97
asyncGeneratorStep @ _async_to_generator.mjs?2154:3
_next @ _async_to_generator.mjs?2154:25
eval @ _async_to_generator.mjs?2154:32
eval @ _async_to_generator.mjs?2154:21
internal @ WASMExample.tsx?bc08:11
eval @ WASMExample.tsx?bc08:15
commitHookEffectListMount @ react-dom.development.js?ac89:23150
commitPassiveMountOnFiber @ react-dom.development.js?ac89:24926
commitPassiveMountEffects_complete @ react-dom.development.js?ac89:24891
commitPassiveMountEffects_begin @ react-dom.development.js?ac89:24878
commitPassiveMountEffects @ react-dom.development.js?ac89:24866
flushPassiveEffectsImpl @ react-dom.development.js?ac89:27039
flushPassiveEffects @ react-dom.development.js?ac89:26984
eval @ react-dom.development.js?ac89:26769
workLoop @ scheduler.development.js?bcd2:266
flushWork @ scheduler.development.js?bcd2:239
performWorkUntilDeadline @ scheduler.development.js?bcd2:533

[Liamolucko]

It seems like the wasm module is getting re-initialized after a closure is created, resetting the Rust code's memory and causing an out-of-bounds error because the memory referenced by the closure no longer exists.

The wasm module gets initialized here:

https://github.com/ivanschuetz/nextjs-wasm-error/blob/8181cf60748c0766d67e7c6de30e5bf766aa2155/src/context/WASM.tsx#L13-L19

That runs after every render (according to a quick skim of React's docs, anyway), and resets the wasm module every time. You need to add some kind of guard to only initialize the wasm module if it's not already initialized (state.wasm === undefined).

[ivnsch]

@Liamolucko thanks, that's it! The effect is running twice because of React's strict mode. With (state.wasm === undefined) there's a race condition and the effect still runs twice, but e.g. using a global variable to lock or disabling strict mode fixes it. Anyway, this is out of topic here, closing.