Does not run with newer Emscripten

[Beuc]

When compiling with 1.38.28, compilation ran fine (just has to replace $(EMSCRIPTEN)/emcc with emcc in the Makefile), but when running test.js within a html page I just get an error:

TypeError: Module.asm.stackSave is undefined

It runs fine with the pre-built version, saved for a TypeError: asm.js type error: Disabled by debugger warning.

[kripken]

Probably needs to call stackSave directly, as the asm object is an internal detail (which has changed over time). And to call it on Module, it should be exported.

[Beuc]

What surprises me is I can't find the call to "stackSave" except in the build results..

[kripken]

What does it look like? Maybe I'll recognize it, or can search for that specific code in emscripten's src/ to find it.

[Beuc]

When compiling with ASSERTIONS=1 I get:

Assertion failed: you need to wait for the runtime to be ready (e.g. wait for main() to be called)

My HTML is like:

<script src="zee.js">
</script>
<script>
...
testSimple();
testBig();
</script>

Maybe things are more asynchronous than in the past - how should one load zee.js?

Anyway I tried commenting out the tests and running them from the console later, but I get:

TypeError: FS.deleteFile is not a function

EDIT: same with -s WASM=0

[kripken]

Yes, wasm starts up async by default. You can disable async compilation (-s BINARYEN_ASYNC_COMPILATION=0) but in chrome that only works on small binaries (to discourage sync compilation).

Usually the proper thing to do is to use Module.onRuntimeInitialized, or otherwise wait for the runtime to load.

[Beuc]

You probably missed my edit: it's the same with WASM=0, while I'd expect ASMJS to start sync.

Also even when waiting there is the other error.

I'd like to use this to load another gzipped wasm (as discussed at https://groups.google.com/forum/#!msg/emscripten-discuss/ORbvqatO9hE/pZcMKTzEAwAJ ), so this would need to work in Chrome, and ideally this would start synchronously because the emscripten bootstrapping is complex enough.
The pre-compiled version fits this, is it not supported anymore?

If that's too complex maybe I need to roll-up my own gunzipper in pure JS :/

[Beuc]

-s WASM=0 --memory-init-file 0 got rid of the start-up issue.
On to the deleteFile one.

[Beuc]

deleteFile->unlink did the trick.
The test suite testBig now fails though:
uncaught exception: Should have been equal: 1048576 : 1145427

[kripken]

asm.js will be async too, when using a mem init file (-O2 and above, by defualt, I believe).

Can use SINGLE_FILE to make asm.js startup synchronous, and for wasm, can disable async compilation if it's small enough (64K or less).

[Beuc]

-s SINGLE_FILE=1 produces the exact same result as with --memory-init-file 0 in this case :)
zee.js is 250-300kB btw.
Any idea about the modified gzip stream issue in the test suite above?

Here's a longer output

# original
testing simple.. test.html:28:3
testing big.. test.html:38:3
           ..generating data.. test.html:53:3
           ..compressing 1048576 bytes.. test.html:60:3
           ..took 0.15 secs test.html:63:3
           ..decompressing 427437 bytes.. test.html:64:3
           ..took 0.01 secs test.html:68:3
           ..got 1048576 bytes.. test.html:69:3
           ..decompressed == original test.html:73:3
ok.

# recompiled -s WASM=0 --memory-init-file 0 + deleteFile->unlink fix
testing simple.. test.html:28:3
testing big.. test.html:38:3
           ..generating data.. test.html:53:3
           ..compressing 1048576 bytes.. test.html:60:3
           ..took 0.17 secs test.html:63:3
           ..decompressing 524288 bytes.. test.html:64:3
           ..took 0.01 secs test.html:68:3
           ..got 1145427 bytes..
uncaught exception: Should have been equal: 1048576 : 1145427

[kripken]

Not sure what could cause that - really weird.

Might be easier to debug with a small testcase maybe?

[Beuc]

It was another early use of the FS module causing 0x00 padding - cf. #4 :)

[Beuc]

I think this is all fixed now.
I didn't push a prebuilt of zee.js/zee-worker.js, not sure if we should.
Thanks again for your responsiveness :)

[kripken]

Thanks for the PRs!

I think pushing builds makes sense to do, could help some people that don't want to build themselves.