RuntimeError: indirect call signature mismatch

[evanw]

This may not be too helpful, but I got RuntimeError: indirect call signature mismatch when I tried to run the result of compiling our app to wasm with release 1.37.5 in Firefox. The generated asm.js code appears to work fine. Is this a known issue? Is it a bug in our code? Or emscripten? Or Firefox?

The call stack wasn't helpful, even with -g:

wasm-function[1100]
wasm-function[790]
wasm-function[720]
wasm-function[2076]
wasm-function[5905]
wasm-function[4348]
wasm-function[4525]
wasm-function[3142]
wasm-function[8401]
wasm-function[2418]
wasm-function[6527]
wasm-function[5565]

[kripken]

It's possible it's an unknown emscripten bug. First thing I would verify what happens in another browser, like chrome canary or safari nightly. Also I'd verify it's latest incoming, as we did fix a bug like that (had to do with imports), but it was a while ago, so probably not the same.

[evanw]

Chrome stable doesn't support WebAssembly yet and so is able to run the asm.js build fine. This says to me that our code is likely correct.

Chrome Canary tries to load the WebAssembly build but gives failed to compile wasm module: RangeError: WebAssembly.Module(): synchronous compilation disallowed due to module size limit set by embedder and falls back to asm.js instead, which works fine. No idea how to bypass this.

Safari Nightly also tries to load the WebAssembly but the generated code throws an abort somewhere when run. It's impossible to tell where because there's no WebAssembly debugging support yet.

Our build system isn't set up to use incoming so I started trying to use the SDK script, but it's taking forever to download. I'm guessing my internet isn't fast enough to download it all at the moment. I'll have to try that again later.

I can also try building with previous emscripten releases. 1.37.1 was working fine when I tried it but 1.37.2 fails to build for unrelated reasons. I can try building with 1.37.3 and 1.37.4 sometime too and maybe that would give more information.

[kripken]

The synchronous compilation issue is a chrome limitation at the moment. Using latest incoming will default to async compilation, avoiding that (or you can set BINARYEN_ASYNC_COMPILATION, in a recent version).

[evanw]

I got our app building with incoming. I tried enabling BINARYEN_ASYNC_COMPILATION but then I get WARNING:root:BINARYEN_ASYNC_COMPILATION requested, but disabled since not in wasm-only mode. Firefox still throws RuntimeError: indirect call signature mismatch. Chrome Canary still shows failed to compile wasm module: RangeError: WebAssembly.Module(): synchronous compilation disallowed due to module size limit set by embedder.

The thing that worked was disabling the asmjs target. Using wasm-only mode gets rid of the warning about BINARYEN_ASYNC_COMPILATION and makes both Firefox and Chrome Canary work.

Is the combined wasm and asm.js mode fully supported (i.e. are you interested in fixing that)? What information would be useful for you to be able to fix it?

[kripken]

Interesting. So the wasm part of the wasm+asmjs build failed, but the wasm by itself build worked? And asm.js of the wasm+asm.js build also worked? Then it seems like somehow wasm is miscompiling the asm.js-friendly asm.js. Weird...

Definitely worth fixing. If you have a runnable bitcode testcase you can share I can debug that. If not, here's how I would debug it: build with -s DETERMINISTIC=1, and also do EMCC_AUTODEBUG=1 in the env. It will then print out lots of logging. You can then get a log from the asm.js and wasm versions of the shared asm.js+wasm build, and diffing them shows where wasm diverges.

[xor2k]

When I tried to get web assembly side modules running, I stumbled upon a similar, maybe the same bug and created a gist: https://gist.github.com/xor2k/6fae4abcb4d8c4b4f456dad39256f9a3

Here, both libc as well as libcxx seem to be included properly, but as soon as std::cout related functions are called, aRuntimeError: indirect call signature mismatch is created.

[kripken]

@xor2k - which version is that with? it works for me on current incoming, using latest binaryen master.

[xor2k]

Yes, I verified that I am using the current emscripten incoming and the latest binaryen master. I'm using Ubuntu 16.4 and the current node.js v8.2.1 from https://nodejs.org/en/download/package-manager. When I try the bundled node-v4.1.1 or node.js v7.10.1 to run node main.js it says no native wasm support detected. I updated the gist so that now the error pops up by default and there is no need to modify the main.cc anymore. Also, I switched from -O2 to -O0 -fno-exceptions. If -fno-exceptions is removed, it yields yet another error. So that gist is acutally a whole error family ;)

[kripken]

Maybe it's a node.js bug? I ran it in the spidermonkey shell. Can you test it in firefox and chrome, those should be the best-supported?

[xor2k]

I also double checked that. Indeed, the bug does not occur with Firefox (v54), but with Chrome (v59) and Chromium (v59). Compare updated gist: https://gist.github.com/xor2k/6fae4abcb4d8c4b4f456dad39256f9a3

[kripken]

Interesting, sounds like a v8-specific bug then. Can you please file a bug for them and link to it here?

[xor2k]

This one here looks promising, I've added another comment: https://bugs.chromium.org/p/v8/issues/detail?id=5913

[xor2k]

Good news! At least the error I have reported seems to be fixed in Node 8.3, Google Chrome v60 and Chromium v60.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.