You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After doing some digging into this, I've found that the problem stems from how Wasm modules expect their imported memory to be configured.
WebAssembly memory buffers must be configured with an initial number of memory pages (64 kb each). The module's bytecode is actually hard-coded with an expected number of initial pages: UniswapV2 query.wasm Module
everything builds and runs just fine. Hooray! Now how do we make this future proof?
Solution
Since it looks like we can no longer assume initial: 1 for all Wasm modules, we should instead check (before instantiation) what the module expects the memory page size to be. How do we fetch this information though? Well we can do a simple search through the bytecode.
Problem
As reported by @krisbitney, we've encountered this error while instantiating one of the UniV3 modules.
The problem stems from this validation step within Chromium's WebAssembly run-time:
https://chromium.googlesource.com/v8/v8/+/644556e6ed0e6e4fac2dfabb441439820ec59813/src/wasm/module-instantiate.cc#924
It is being thrown when we run:
Root Cause
After doing some digging into this, I've found that the problem stems from how Wasm modules expect their imported memory to be configured.
WebAssembly memory buffers must be configured with an
initial
number of memory pages (64 kb each). The module's bytecode is actually hard-coded with an expected number of initial pages:UniswapV2 query.wasm Module
and
UniswapV3 query.wasm Module
Notice the difference? The
import
command for theenv.memory
object is defined differently, using the number2
instead of1
.If we look at the Wasm bytecode standard, we can see that the memory import configuration is represented like so:
https://github.com/sunfishcode/wasm-reference-manual/blob/master/WebAssembly.md#linear-memory-description
If we change our above JavaScript code to:
everything builds and runs just fine. Hooray! Now how do we make this future proof?
Solution
Since it looks like we can no longer assume
initial: 1
for all Wasm modules, we should instead check (before instantiation) what the module expects the memory page size to be. How do we fetch this information though? Well we can do a simple search through the bytecode.If we take the following
wat
code:and run
wat2wasm ./test.wat -d
we get:From this we can extract the following bytecode signature:
And now we simply do an
indexOf(...)
and we have ourinitial
memory page size:Now, regardless of how the Wasm module is compiled, we can always match the exact memory page layout it's expecting.
The text was updated successfully, but these errors were encountered: