-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Upstream: Safari - WebAssembly.instantiate throws Error: WebAssembly.Module doesn't parse at byte: invalid opcode, in function at index #9842
Comments
Looks like this is a bulk memory operation. AFAIK those shouldn't get emitted unless you've enabled them, explicitly or implicitly (maybe with something like pthreads, which also wouldn't be supported on Safari yet). |
Threading is explicitly disabled for the emscripten export. What other C++ memory operations would cause that? I mean, It's instantiating fine in Chrome and Firefox, and using fastcomp it also works in Safari, so it can't be too wrong. |
The easiest way to debug is probably to run your binary thought |
I can confirm the same behavior in one of my wasm builds. Works in Chrome/Firefox, but not in Safari. Works in all Browsers with the old fastcomp backend. I get this error in Safari: Running |
I looks like So the question is, how is this instruction ending in your binary? Can you use |
🤦♂ ... ooops, i actually do have -mnontrapping-fptoint somewhere in my Makefile |
That's correct. I fell for the trap: "LLVM wasm backend of thinking, that this was a replacement for -s "BINARYEN_TRAP_MODE='clamp'" Maybe add a link to a list of browser showing their support for the newer vs the older VW? |
If you can find such a link feel free to add it to the docs. My feeling is that they are pretty clear already but happy to accept a PR. In the mean time I guess we can close this issue? |
This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 30 days. Feel free to re-open at any time if this issue is still relevant. |
@haberbyte could you assist with a similar problem, as I'm new to wasm. I get this error: Here is my datastore of the wasm and core js files and here is my code that loads the data and initializes both let coreData = (await db.getFile("core")) as any;
let wasmData = (await db.getFile("wasm")) as any;
const coreBlob = new Blob([coreData.data], { type: "text/javascript"});
const wasmBlob = new Blob([wasmData.data], { type: "application/wasm"});
const ffmpeg = ffmpegRef.current;
await ffmpeg.load({
coreURL: fromBlobToURL(coreBlob),
wasmURL: fromBlobToURL(wasmBlob),
}); This works fine on android, and windows. but I get that error (first image) when testing on iOS iPhone 13 v16.3 |
@DeanVanGreunen perhaps you want to open a new issue? Can you share (in that issue) the full list of link flags you used to build the wasm binary, and the emscripten version? If you can perhaps attach the wasm file itself too. |
@sbc100 I used this wasm version of ffmpeg ffmpeg-core 0.12.2 not sure what flags it was built with. |
Found, what I would call a bug, when compiling using fastcomp vs upstream.
upstream:
Chrome and Firefox are fine. Safari 12 on desktop and mobile won't instantiate the wasm module throwing:
That's all, no other information from Safari.
It's working with fastcomp and with upstream in Firefox and Chrome.
So how would I go about fixing this?
The text was updated successfully, but these errors were encountered: