Repository navigation
wasi.start() throws type error #33415
Description
Activity
Jest runs your code in a VM sandbox (think
require('vm').runInNewContext('/* your code */')) and that sandbox has its own copies of the built-in globals.When your code calls out to the outer context, the
instance instanceof WebAssembly.Instancecheck inlib/wasi.jsfails because it's a different instance of, er,Instance.I think that check and the
WebAssembly.Memorycheck can be removed without ill effects, as long as the argument duck-types as aWebAssembly.Instanceobject.Do you want to open a PR? It should come with tests in
test/wasithat checks various kinds of valid and invalid inputs.Glad I wasn't crazy. I had to implement a very hacky workaround for my testing software involving obtaining all the symbols directly and calling the setMemory function directly.
I suppose I could submit a lib/wasi.js fix for this.
Might need some help with making the tests.
@bnoordhuis , I'm a first time contributer. Is there any chance I could get some help with starting my pull request?
Edit: Actually, my computer has only about 3 gigs worth of space left on it, and compiling all the test modules seems to eat it all up. I'm currently doing most of my dev work on a microsoft surface, so I won't be able to contribute to fix this.
- added a commit that references this issue
on May 16, 2020 No problem. I've opened #33431.
Workaround is not fun, but it's doable.
wasi.start = jest.fn((instance) => { const symbols = Object.getOwnPropertySymbols(wasi); const kStartedSymbol = symbols.filter((symbol) => symbol.toString().includes("kStarted"), )[0]; const setMemorySymbol = symbols.filter((symbol) => symbol.toString().includes("setMemory"), )[0]; wasi[setMemorySymbol](instance.exports.memory); wasi[kStartedSymbol] = true; instance.exports._start(); });
I hope this helps someone in the meantime.
- added a commit that references this issue
on May 23, 2020 - added 2 commits that reference this issue
on Jun 18, 2020 - added a commit that references this issue
on Jun 30, 2020 - added a commit that references this issue
on Jul 8, 2020
What steps will reproduce the bug?
I am not sure exactly how to reproduce this bug, but when I use
jest, I run the following code.How often does it reproduce? Is there a required condition?
I doubt this is jest related, and it looks like
wasiseems to have a different version ofWebAssembly.Instance, because it logs true.Related question: Is it possible that
jestwould modify theWebAssemblyclass?What is the expected behavior?
I suppose that the module shouldn't throw an error, because it appears to be an instance of an
Instance.What do you see instead?
Additional information
I will be happy to help debug this, but it's currently 3am. Will update this with an appropriate script to replicate this without jest.
EDIT: Removed postfix
!operators because they are typescript related. Whoops.