-sSINGLE_FILE: embedded wasm string decodes to 1 extra byte (0x20), producing invalid wasm (large binaries)

[ronen-blumberg]

Version

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 6.0.6 (ce75e06)
clang version 24.0.0git (llvm-project ff6d537b14d737719d6377789784d04ff9565f65)
Target: wasm32-unknown-emscripten
Installed via emsdk "latest" on Linux x86_64 (Devuan).

Problem

Building with -sSINGLE_FILE produces an .html whose embedded wasm fails to
instantiate in Firefox 140 ESR:

CompileError: wasm validation error: at offset 8421340: invalid data initializer-kind field

The same project built without -sSINGLE_FILE produces a .wasm that
wasm-opt --all-features validates and that runs correctly in the same browser.

This emcc version embeds the wasm as a raw JS string literal decoded by:

function binaryDecode(f){for(var b,v=0,n=f.length,t=new Uint8Array(n);v<n;++v)b=f.charCodeAt(v),t[v]=~b>>8&b;return t}

(not base64 as older versions did).

What I found

• Reference (multi-file) wasm: 15,022,632 bytes, valid.

• Saving the result of findWasmBinary() from the browser on the single-file
  build gives 15,022,633 bytes — one extra byte.

• Byte-level comparison: a single 0x20 (space) is present at decoded offset
  8,417,950 that does not exist in the reference wasm. Every byte before it
  is identical; every byte after is identical but shifted by one. The validation
  error at offset 8,421,340 is the parser failing on the shifted data a few KB later.

• The spurious space physically exists in the emitted .html: inside the embedded
  string literal, between a literal > character and a \f escape sequence.
  The surrounding emitted text (escapes shown as written in the file):

  2\r%> \f%3
  

  decodes to reference bytes 32 0d 25 3e | 0c 25 33 — the space between >
  and \f corresponds to nothing in the reference binary. So this is an
  encode-side defect (the emitted string already contains the extra byte),
  not a browser/decoding problem.

• Possibly relevant observation: escaping in the emitted string is inconsistent —
  e.g. byte 0x0C appears in some places as a raw control character and in other
  places as \f — which may suggest a post-processing pass (HTML/JS
  minification?) rewriting whitespace-class characters inside the string literal
  after emission.

• Counter-test: embedding the identical wasm bytes as a base64 data: URI
  in the same .html loads and runs perfectly.

• Size dependence: small programs (hello-world size) built with -sSINGLE_FILE
  work fine. Two separate large projects fail the same way: a ~15 MB wasm
  (extra byte at 8,417,950) and a ~7.5 MB wasm (validation error at 7,490,125).

Link flags used

-sSINGLE_FILE -sASYNCIFY -sALLOW_MEMORY_GROWTH=1 -sMAXIMUM_MEMORY=1073741824
-sEXPORTED_RUNTIME_METHODS=stringToNewUTF8 --shell-file <custom shell> -Oz

The C source is generated by the FreeBASIC compiler's emscripten target
(fbc -target js-asmjs), which drives emcc for compile and link.

Reproduction

Happens consistently for me with multi-MB wasm binaries. The failing .html is
~18 MB — happy to provide it, the matching reference .wasm, and exact byte
offsets on request, or to test candidate fixes / run with EMCC_DEBUG=1.

[sbc100]

It sounds like this is bug related to the SINGLE_FILE_BINARY_ENCODE setting.

When you say "embedding the identical wasm bytes as a base64 data: URI
in the same .html loads and runs perfectly" did you do this by hand or did you use the -sSINGLE_FILE_BINARY_ENCODE=0 option. Can you confirm that -sSINGLE_FILE_BINARY_ENCODE=0 does indeed fix the issue.

I'm curious if the issue relates to the embedding of the binary in the JS file or the embedding the resulting JS in the html.

Perhaps I'll list the questions I have in order:

1. Can you confirm that -sSINGLE_FILE_BINARY_ENCODE=0 does indeed fix the issue?
2. If you build your program as a .js file (so out.s -sSINGLE_FILE) rather than html, does the resulting code load and run?
3. Does the same file work on other browser (e.g. chrome). (I only ask because you explicitly call out Firefox).

[ronen-blumberg]

Ran your experiments:

1. -sSINGLE_FILE_BINARY_ENCODE=0: confirmed — it fixes it. The html loads and the program runs normally. (My earlier base64 counter-test was done by hand — I extracted the multi-file .wasm and embedded the same bytes as a base64 data: URI myself — so this matches.)

2. -o .js with -sSINGLE_FILE (default string encoding): works. Loaded from a minimal host html, the wasm instantiates and the program runs — same browser, same encoder. So the binary→JS string embedding appears correct, and the corruption is introduced when producing the .html output. On-disk confirmation: the .html contains the corrupted emitted text 2\r%> \f%3 (spurious space; decodes to an extra 0x20 at wasm offset 8,417,950), and that corrupted sequence does not appear anywhere in the working .js. Interestingly the .js also writes that region with different escaping than the .html does, which again suggests the html path rewrites the embedded string after emission (matching my earlier observation that in the html, byte 0x0C appears sometimes raw and sometimes as \f).

3. I don't have Chrome installed, but given (2) — same encoder, same browser, works as .js and fails as .html — plus the spurious space being physically present in the .html bytes on disk, this looks browser-independent rather than a Firefox parsing issue.

Summary: SINGLE_FILE + string encode + .js output = fine; SINGLE_FILE + string encode + .html output = corrupted; SINGLE_FILE + BINARY_ENCODE=0 + .html = fine. Happy to run anything else (EMCC_DEBUG, candidate patches).

[sbc100]

Ah, this issue I believe was already fixed in #27509. This change shipped as part of 6.0.7. Can you confirm that using 6.0.7 or above fixe this issue?