`WebAssembly.instantiate(): illegal flag value 90 @+642213` when `-sSINGLE_FILE=1` in release build

[sefyan0hack]

when using -sSINGLE_FILE=1 in Release i get this Error in the browser console dev tool

failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): illegal flag value 90 @+642213

index.html:1 Uncaught (in promise) TypeError: A.startsWith is not a function
    at isFileURI (index.html:1:4330)
    at instantiateArrayBuffer (index.html:1:9272375)
    at async createWasm (index.html:1:9273430)

index.html:1:4330 is var isFileURI = A => A.startsWith("file://");

Version of emscripten/emsdk:

GameEngine\build>emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 6.0.0 (afa15e0c56d1292e073c2c91bafc1d5e0cdf0dd3)
clang version 23.0.0git (https:/github.com/llvm/llvm-project c6c2ad52586c28e74a724570985a48dc0022d250)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: C:\emsdk\upstream\bin

Emscripten compile/link flags

target_link_libraries(Engine PUBLIC
       $<$<PLATFORM_ID:Emscripten>:
            --shell-file ${CMAKE_SOURCE_DIR}/cmake/index.html
            -sMIN_WEBGL_VERSION=2
            -sFULL_ES3=1

            -sALLOW_MEMORY_GROWTH=1

            -sDISABLE_EXCEPTION_THROWING=0
            -sDISABLE_EXCEPTION_CATCHING=0

	        -sSINGLE_FILE=1
            -sASSERTIONS=2

            $<$<CONFIG:Debug>:
                -sEXCEPTION_STACK_TRACES=1
                -sSTACK_OVERFLOW_CHECK=2
                -sSAFE_HEAP=1
                -sGL_ASSERTIONS=1
                -sGL_DEBUG=1
                -gsource-map
            >
        >
)

project: https://github.com/sefyan0hack/GameEngine
hosted on github pages: https://sefyan0hack.github.io/GameEngine/Release

index.html

[kripken]

This could be a bug in SINGLE_FILE.

1. Does this still happen without that flag?
2. Does this happen on latest main? (emsdk install tot)

[sbc100]

I think the problem is likely the illegal flag value 90 @+642213. I.e. maybe the wasm file is actually invalid in some way.

[sefyan0hack]

This could be a bug in SINGLE_FILE.

1. Does this still happen without that flag?
2. Does this happen on latest main? (emsdk install tot)

1. it happens in release build (Only) when SINGLE_FILE=1.
   not in debug build even if SINGLE_FILE=1 or 0
2. I don't know exactly. I'm using GitHub CI to automatically fetch the latest Emscripten SDK with the GitHub Action emscripten-core/setup-emsdk@v16.
   My project is public, and I think it's a fairly simple CMake build for the web. All of my dependencies are either vendored into the repository or included as Git submodules, so the issue should be reproducible

[sefyan0hack]

I think the problem is likely the illegal flag value 90 @+642213. I.e. maybe the wasm file is actually invalid in some way.

yes not file maybe when embeded to the js or html not encoded correctly some edge case maybe and this with happens only when some combination of flags with SINGLE_FILE maybe flags i use
shared flags (debug/release)

--shell-file ${CMAKE_SOURCE_DIR}/cmake/index.html
-sMIN_WEBGL_VERSION=2
-sFULL_ES3=1
-sALLOW_MEMORY_GROWTH=1
-sDISABLE_EXCEPTION_THROWING=0
-sDISABLE_EXCEPTION_CATCHING=0
-sSINGLE_FILE=1
-sASSERTIONS=2

(debug)

-sEXCEPTION_STACK_TRACES=1
-sSTACK_OVERFLOW_CHECK=2
-sSAFE_HEAP=1
-sGL_ASSERTIONS=1
-sGL_DEBUG=1
-gsource-map

[sbc100]

The embedded wasm file does look invalid for some reason.

I'm attached a copy of it:

index.wasm.zip

Wabt seems to agree about the issue:

wasm-validate ~/index.wasm 
009cca6: error: invalid data segment flags: 0x5a

Binaryen sees a different issue:

wasm-dis ~/index.wasm 
[parse exception: Section extends beyond end of input (at 0:8946479)]
Fatal: error parsing wasm (try --debug for more info)

I guess this could be some kind of issue with out binary embedding?

Is your index.html file encoded as UTF-8? Does -sSINGLE_FILE_BINARY_ENCODE=0 fix the issue? @juj any ideas?

[sefyan0hack]

The embedded wasm file does look invalid for some reason.

I'm attached a copy of it:

index.wasm.zip

Wabt seems to agree about the issue:

wasm-validate ~/index.wasm 
009cca6: error: invalid data segment flags: 0x5a

Binaryen sees a different issue:

wasm-dis ~/index.wasm 
[parse exception: Section extends beyond end of input (at 0:8946479)]
Fatal: error parsing wasm (try --debug for more info)

I guess this could be some kind of issue with out binary embedding?

Is your index.html file encoded as UTF-8? Does -sSINGLE_FILE_BINARY_ENCODE=0 fix the issue? @juj any ideas?

yes -sSINGLE_FILE_BINARY_ENCODE=0 fixes the broblem for me

[sbc100]

I assume this must be something about the html file encoding is setup. See the docs for SINGLE_FILE_BINARY_ENCODE: https://emscripten.org/docs/tools_reference/settings_reference.html#single-file-binary-encode.

I wonder if we can do better at detecting and reporting this kind of problem? @juj?

[sefyan0hack]

I assume this must be something about the html file encoding is setup. See the docs for SINGLE_FILE_BINARY_ENCODE: https://emscripten.org/docs/tools_reference/settings_reference.html#single-file-binary-encode.

I wonder if we can do better at detecting and reporting this kind of problem? @juj?

i have <meta charset="utf-8"> in custom shel. index.hmtl

<!DOCTYPE html>
<html lang="en-US">
<head>
  <meta charset="utf-8"> 
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
  <style>
    #canvas { padding-right: 0; margin-left: auto; margin-right: auto; display: block; border: 0px none; background-color: black;}
  </style>
</head>
<body>
  <canvas id="canvas" oncontextmenu="event.preventDefault()" tabindex=-1></canvas>
  {{{ SCRIPT }}}
</body>
</html>```

[sbc100]

Out of interest, what are your actual requirements? Do you need to JS to be embeded into the html or would it be enough to embed the wasm into the JS?

[sefyan0hack]

Out of interest, what are your actual requirements? Do you need to JS to be embeded into the html or would it be enough to embed the wasm into the JS?

I really liked using a single-file WASM build embedded into JS but I set set_target_properties(${target} PROPERTIES SUFFIX ".html") so it gets embedded into HTML via Emscripten. This way, no server is required. I’m also embedding all of my resources just to iterate faster on my project.

[sbc100]

Do you find that these embedding actually make things faster?

In any case it sounds like you have a workaround for now in the form of -sSINGLE_FILE_BINARY_ENCODE=0. Its still a mystery exactly why its not working your case, and its good we kept that options for around for cases like this.

[sbc100]

One more thing: Are you attached to having Emscripten generate your html? For most users we just recommend generating the .js and then having the .html maintained by hand.

[sefyan0hack]

Do you find that these embedding actually make things faster?

In any case it sounds like you have a workaround for now in the form of -sSINGLE_FILE_BINARY_ENCODE=0. Its still a mystery exactly why its not working your case, and its good we kept that options for around for cases like this.

not about the speed it just makes my cmake pack system simple i was dowing the .js then by hand including it but i found out i could use --shell-file and set CMAKE_PREFIX to "html" only need to pack .html alone. if this bug not bad ok you can close this issue but maybe its far more than this and affecting other thing ?

[sefyan0hack]

One more thing: Are you attached to having Emscripten generate your html? For most users we just recommend generating the .js and then having the .html maintained by hand.

yeh both options are good for me i dont care if i or cmake generates the html but the --shell-file whats its purpose ?

[sbc100]

--shell-file I think kind of serves 2 purposes:

1. As a starting point: It allows emscripten to generate a starting point for an html file so folks can see their program running right away. Once such users has a taken a look at the generated HTML they would normally just create their own site and embed the JS directly.
2. A way to have single HTML file for for may targets: For example if you are building a higher level SDK on top of emscripten you might have not want to create your own html-generated and instead just use s simple html template that you pass to --shell-file. This not a very common case though, since more users have a fixed/static number of targets which don't share html-embedding needs.

For the first case we don't even need the --shell-file option, we just need single template embedded in emscripten.

The second case is really very rare I think. Maybe it could used to unit testing of demo generation where each program has the came html-embedding needs? But its also very trivial to write a html-generated-based-on-template outside of emscripten. For this reason I'd really like to remove --shell-file one day. html-templating is not a the core competency of emscripten, we should expect higher level tools to do that.