Sum.js:634 failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): section was shorter than expected size (18371 bytes expected, 207 decoded) @+219

Thomas Grund

unread,

Oct 30, 2025, 9:02:16 AM (9 days ago) Oct 30

to emscripten-discuss

Hello,

The following example does

not work with current emcc 4.0.18 in Chrome.

It

works with current emcc 4.0.18 in Firefox and it
works with emcc 4.0.16 in Chrome.

I use local files on Windows 11.

Example index.html:

<!DOCTYPE html>
<html>
<head>
<script>
function compute() {
a=parseFloat(document.getElementById('a').value);
b=parseFloat(document.getElementById('b').value);
document.getElementById('c').innerText = Module.Sum(a, b);
}
</script>
<script src="Sum.js"></script>
</head>
<body>
<input id="a" type="number" onchange="compute()">
<input id="b" type="number" onchange="compute()">
<div id="c">Result</div>
</body>
</html>

Example Sum.cpp:

#include <emscripten/bind.h>

double Sum(double a, double b) {
return a+b;
}

EMSCRIPTEN_BINDINGS(Module) {
emscripten::function("Sum", &Sum);
}

Compile with:

emcc -o Sum.js Sum.cpp -sSINGLE_FILE --bind -sASSERTIONS

Error in Chrome Console:

failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): section was shorter than expected size (18371 bytes expected, 207 decoded) @+219
instantiateArrayBuffer @ Sum.js:634
await in instantiateArrayBuffer
instantiateAsync @ Sum.js:645
createWasm @ Sum.js:713
(anonymous) @ Sum.js:2761Understand this error
Sum.js:275 Uncaught (in promise) TypeError: filename.startsWith is not a function
isFileURI @ Sum.js:275
instantiateArrayBuffer @ Sum.js:637
await in instantiateArrayBuffer
instantiateAsync @ Sum.js:645
createWasm @ Sum.js:713
(anonymous) @ Sum.js:2761Understand this error
Sum.js:794 still waiting on run dependencies:
(anonymous) @ Sum.js:794
setInterval
addRunDependency @ Sum.js:784
createWasm @ Sum.js:674
(anonymous) @ Sum.js:2761Understand this error
Sum.js:796 dependency: wasm-instantiate
(anonymous) @ Sum.js:796
setInterval
addRunDependency @ Sum.js:784
createWasm @ Sum.js:674
(anonymous) @ Sum.js:2761Understand this error
Sum.js:799 (end of list)
(anonymous) @ Sum.js:799
setInterval
addRunDependency @ Sum.js:784
createWasm @ Sum.js:674
(anonymous) @ Sum.js:2761Understand this error

What am I doing wrong?

Thanks for your help!

Thomas

Alon Zakai

unread,

Oct 30, 2025, 1:32:45 PM (8 days ago) Oct 30

to emscripte...@googlegroups.com

Thanks for reporting, this turns out ot be a recent regression in SINGLE_FILE. I bisected to

https://github.com/emscripten-core/emscripten/pull/25599

and posted there.

- Alon

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/504419d6-cdcf-4eec-9a1e-e7f69f87a129n%40googlegroups.com.

Alon Zakai

unread,

Oct 30, 2025, 1:33:58 PM (8 days ago) Oct 30

to emscripte...@googlegroups.com

Note that it fails for me in both Chrome and Firefox, I don't see a browser difference.

Thomas Grund

unread,

Oct 31, 2025, 11:54:19 AM (8 days ago) Oct 31

to emscripten-discuss

Thanks for analyzing!

Thomas

Sam Clegg

unread,

Oct 31, 2025, 5:37:32 PM (7 days ago) Oct 31

to emscripte...@googlegroups.com

BTW, if you want to get things working quickly you should be able use `-sSINGLE_FILE_BINARY_ENCODE=0`. This setting was added specifically in case a bug this showed up/

cheers,

sam

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/5b591cef-ad8e-467f-95dc-b43719e21086n%40googlegroups.com.

jj

unread,

Nov 3, 2025, 9:05:46 AM (5 days ago) Nov 3

to emscripten-discuss

Thanks for reporting this.

This was due to a planned change, although we did not sufficiently highlight what is going on in this case.

Recently we migrated the SINGLE_FILE mode to no longer use base64, but directly embed the binary content in a UTF-8 encoded string. However, this change requires that the served files are explicitly annotated to be encoded as UTF-8, or otherwise browsers default to legacy behavior, and assume Windows CP1252 encoding. (maybe on Windows only, not completely sure)

A quick fix is to add <meta charset='utf-8'> in the <head> section of the above index.html. That will cause the browser to change the defaults also for all downloaded .js files to UTF-8.

The PR https://github.com/emscripten-core/emscripten/pull/25134 internally addressed the change in encoding, and I was thinking that would transparently cover every use case. I.e. originally I had a mindset that users of SINGLE_FILE would all be doing "-sSINGLE_FILE -o foo.html", i.e. they'd be generating a single .html file as output.

Though in your above example, you are doing "-sSINGLE_FILE -o foo.js", to use the single file mode in a "two file" mode, by then manually providing a index.html file. That use then would not automatically get the UTF-8 encoding declaration.

Testing locally, I see that adding <meta charset='utf-8'> in the <head> section fixes up the test case.

Authored a PR https://github.com/emscripten-core/emscripten/pull/25704 to help users be aware that declaring the UTF-8 encoding is now explicitly necessary for SINGLE_FILE mode - the legacy Windows CP1252 will unfortunately no longer work with SINGLE_FILE in binary encoding mode. If Windows CP1252 is needed for some reason, one can still fall back with -sSINGLE_FILE_BINARY_ENCODE=0 like Sam mentioned.

Thomas Grund

unread,

Nov 3, 2025, 10:10:29 AM (5 days ago) Nov 3

to emscripten-discuss

Thanks for clarifying this and it is working now with encoding set to UTF-8.

One advantage is the smaller file size.

Another small point that comes up: The output file (here Sum.js) is not a text file anymore in the sense that the file contains zero bytes \x00 now. So for handling this (load Sum.js and copy it to another html file) we have to switch to binary file handling which is not a problem at all.

Thanks again

Thomas

Sam Clegg

unread,

Nov 3, 2025, 12:51:40 PM (4 days ago) Nov 3

to emscripte...@googlegroups.com

On Mon, Nov 3, 2025 at 7:10 AM Thomas Grund <thomas.g...@gmail.com> wrote:

Thanks for clarifying this and it is working now with encoding set to UTF-8.
One advantage is the smaller file size.
Another small point that comes up: The output file (here Sum.js) is not a text file anymore in the sense that the file contains zero bytes \x00 now. So for handling this (load Sum.js and copy it to another html file) we have to switch to binary file handling which is not a problem at all.

Interesting yes, this is a little unfortunate:

```
$ emcc ~/test/hello.c -sSINGLE_FILE
$ file a.out.js
a.out.js: data

$ emcc ~/test/hello.c -sSINGLE_FILE -sSINGLE_FILE_BINARY_ENCODE=0
$ file a.out.js
a.out.js: JavaScript source, ASCII text, with very long lines (20202)

```

Although I guess this doesn't really have any practical downsides, is that right Jukka?

To view this discussion visit https://groups.google.com/d/msgid/emscripten-discuss/06422e62-f8a8-4c17-953a-d72bee8d0108n%40googlegroups.com.

Reply all

Reply to author

Forward