[BUG] WebAssembly.Module doesn't parse at byte 1227: invalid opcode 192, in function at index 28

[indykoning]

Describe the bug

On Ipad safari the webassembly script fails to compile due to the following error:

failed to asynchronously prepare wasm: CompileError: WebAssembly.Module doesn't parse at byte 1227: invalid opcode 192, in function at index 28

To Reproduce

Opening the example on an ipad and uploading an image file of a barcode https://undecaf.github.io/zbar-wasm/example/ will result in "Source not ready" with the specified error above.

Or else the environment in which the behavior occurs needs to be specified:

• Which target environment (Node/browser/other)? IOS Safari (on Iphone/Ipad, Macbook works fine)
• Which type of modules (ESM/CommonJS/other)? CommonJS Version 0.10.1, 0.9.16, 0.9.15, 0.9.14

[undecaf]

Which iOS version and Safari version have you been using for the example?

[indykoning]

Unfortunate for debugging, but fortunate for me the Ipad had updated to IOS 16.7.5 which has resolved the issue.
I'm guessing it was most likely the older browser not supporting some of the opcodes used in the wasm file

I will close this for now as i am no longer able to reproduce the issue

[erickedji]

@undecaf We still get production logs about this issue, from browsers as recent as Safari 16.6 on iPhone 16.7.2 (released in July 2023).

I found pointers here for making the webassembly module compatible with a wider set of browsers: emscripten-core/emscripten#19121

[undecaf]

@erickedji According to this table, Safari should support WASM sign-extension since 14.5 on iOS. I just verified the example to work also under Safari 16.2 which also is older than the version you mentioned.

Therefore it seems unlikely that sign-extension operations are the cause for your production logs. Since I do not wish to disable all new WASM features only to be on the safe side, could you please be more specific on what exactly is being logged?

[erickedji]

Indeed, that was my mistake. The highest version this "opcode 192" error was detected on is 14.0, which is consistent with the compatibility data.

The error on 16.7.2 is slightly different.

The full user agent is:

Mozilla/5.0 (iPhone; CPU iPhone OS 16_7_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6 Mobile/15E148 Safari/604.1

The error message is:

Aborted(CompileError: WebAssembly.Module doesn't parse at byte 100282: Data section of size 138735 would overflow Module's size). Build with -sASSERTIONS for more info.

This was caught with a global unhandledrejection listener on window.

Should I create another issue?

[undecaf]

@erickedji I think that the error message does not indicate that there is anything wrong with the WASM file: zbar.wasm v0.9.16 does contain a data section that starts at offset 100282 (0x0187BA), and it is indeed 138735 (0x021DEF) bytes long, and it extends up to the the last byte of the WASM file at offset 239016 (0x03A5A8), as can be seen in the WebAssembly Code Explorer (EF BB 08 is 138735 in unsigned LEB128 encoding):

The WASM validation utility (wasm-validate) reports the file to be valid, too, using only sign-extension as an advanced feature:

wasm-validate --disable-mutable-globals --disable-simd --disable-bulk-memory --disable-saturating-float-to-int --disable-multi-value --disable-reference-types zbar.wasm

Therefore I think that your error message could be the result of too little memory for Safari, or maybe even a bug in Safari 16.6

[erickedji]

Thanks for the investigation @undecaf
I checked the logs and found other Safari 16.6 visitors without that issue (only one visitor with the issue), so we can keep this closed.