Safari 14.0 - Error: WebAssembly.Module doesn't parse at byte 60824: invalid section

[jwtowner]

I'm getting the following error when attempting to load a module:

failed to asynchronously prepare wasm: CompilerError: WebAssembly.Module doesn't parse at byte 60824: invalid section

Any idea as to how to figure out what this section is or what feature we might be using that is incompatible with Safari? Thanks.

[sbc100]

You can try using a tool like wasm-objdump (part of wabt) to see what is at that location.

It could also be some kind of issue with your webserver.. you could try verifying the the bytes recieved by the browser are the same as the bytes sitting on your webserver (using devtools to save the .wasm file).

If you can, you could also upload the .wasm here and somebody could take a look at the bytes.

[jwtowner]

It looks like it's a single byte DataCount section, which I assume is added when bulk memory operations are used. We aren't compiling with -pthread or -s USE_PTHREADS=1 or anything of that nature. We are still using C++ atomics in some places so we don't have to conditionally compile out that code and replace it with atomic-free code path.

Any idea what else could be adding in that DataCount section?

This is with both EMSDK 2.0.30 and 3.0.0

[sbc100]

Can you try building with EMCC_DEBUG=1 and see if the direct output of wasm-ld contains the data count section or if it is added by some later stage?

[jwtowner]

Yes, looks like it's getting added at a later stage, the direct output from wasm-ld doesn't have that section. Looking at the build logs with EMCC_DEBUG=1, it looks like wasm-opt is being passed --enable-threads --enable-mutable-globals --enable-bulk-memory --enable-sign-ext. Looks like wasm-emscripten-finalize is detecting those features.

Here's the build log: build.log

[sbc100]

I think perhaps you have at least one object being linked in that was compiled with -pthread or -s USE_PTHREADS. That would result in wasm-ld adding those features to its output.

Can you verify using wasm-objdump that the output of wasm-ld contains the mutable globals feature in the features section?

I'm not sure there is good way to ask wasm-ld to report why each feature was included (i.e. which object file needed it). We should probably add some logging/tracing to Writer::populateTargetFeatures in lld/wasm/Writer.cpp.

[sbc100]

BTW its find to use C++ atomics as long as you don't pass -pthread to the compiler... in this case all the atomics will get lowered away by llvm at compile time. If all objects have their atomics lowered away you won't see the threads feature in the features section.

[sbc100]

@tlively what do you think about adding some debugging here to wasm-ld can tell you why its including each feature?

[jwtowner]

Can you verify using wasm-objdump that the output of wasm-ld contains the mutable globals feature in the features section?

Didn't see a features section, but noticed there was this custom section at the end of the module.

Contents of section Custom:
ff215b8: 0f74 6172 6765 745f 6665 6174 7572 6573  .target_features
ff215c8: 042b 0761 746f 6d69 6373 2b0b 6275 6c6b  .+.atomics+.bulk
ff215d8: 2d6d 656d 6f72 792b 0f6d 7574 6162 6c65  -memory+.mutable
ff215e8: 2d67 6c6f 6261 6c73 2b08 7369 676e 2d65  -globals+.sign-e
ff215f8: 7874                                     xt

[jwtowner]

I think I've discovered the culprits, there's some third party libraries we're statically linking with that seem to have those features present in their object files. I will investigate why our build options aren't being passed to them during build time. Hopefully, that's all it is. Thanks for the help!

[jwtowner]

Yeah that was the problem, fixing those third party libraries has solved the issue. Thanks again!