Firefox: Module.asm is undefined

[Dirk Vanden Boer]

Hi,

I created a webassembly project that runs fine in Google Chrome, but in firefox I get the following error:

failed to asynchronously prepare wasm: TypeError: Module.asm is undefined  gdx-wasm.js:1:17745

TypeError: Module.asm is undefined

Stack trace:

Module.__GLOBAL__I_000101@http://127.0.0.1:8080/gdx-wasm.js:1:316269

func@http://127.0.0.1:8080/gdx-wasm.js:1:50681

callRuntimeCallbacks@http://127.0.0.1:8080/gdx-wasm.js:1:37234

ensureInitRuntime@http://127.0.0.1:8080/gdx-wasm.js:1:37753

doRun@http://127.0.0.1:8080/gdx-wasm.js:1:332118

run@http://127.0.0.1:8080/gdx-wasm.js:1:332558

runCaller@http://127.0.0.1:8080/gdx-wasm.js:1:330813

removeRunDependency@http://127.0.0.1:8080/gdx-wasm.js:1:42608

receiveInstance@http://127.0.0.1:8080/gdx-wasm.js:1:46417

doNativeWasm/<@http://127.0.0.1:8080/gdx-wasm.js:1:46794

Any hints on how to fix this?

Thanks

[Alon Zakai]

I would guess there is a too-early call into compiled code, confounded by a timing issue, and it happens one browser's startup is slower and is after Module.asm exists, so it seems to work there. To check that theory, try a build with -s ASSERTIONS=1 , that should check calls at runtime. If it is in fact the case, see http://kripken.github.io/emscripten-site/docs/getting_started/FAQ.html#how-can-i-tell-when-the-page-is-fully-loaded-and-it-is-safe-to-call-compiled-functions

--
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-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dirk Vanden Boer]

I already built with -s ASSERTIONS=1 as it was a suggestion in the error, but it doesn't seem to change anything.

I'm waiting for the onRuntimeInitialized callback before doing calls.

This is also printed in the console:

uncaught exception: abort({}) at jsStackTrace@http://127.0.0.1:8080/gdx-wasm.js:1:33098
stackTrace@http://127.0.0.1:8080/gdx-wasm.js:1:33269
abort@http://127.0.0.1:8080/gdx-wasm.js:1:333639
doNativeWasm/<@http://127.0.0.1:8080/gdx-wasm.js:1:46926

[Alon Zakai]

Ok, you may be hitting an unknown bug then. Can you provide a testcase showing the issue? If not, I would debug this by adding a bunch of console.logs in relevant places (where Module.asm is assigned to, where you start the call that aborts, etc.).

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dirk Vanden Boer]

Alright, I'll try to simplify the program tomorrow and get back to you.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dirk Vanden Boer]

While creating a minimal reproduction scenario, chrome also broke. So I knew I had to do something wrong :-)

I was including the gdx-wasm.js script (created by emcc) in the head and my own js script (which sets up the module callback) in the body.

Including the gdx-wasm.js script in the body AFTER my own js script solved the issue.

So although i wasn't doing calls in the module, setting up the module onRuntimeInitialized callback while the wasm is being loaded causes these kind of issues?

[Alon Zakai]

Hmm, I still don't understand this. In particular, when ASSERTIONS is on, you should never see an error like "Module.asm is undefined" since we should guard against it - so somehow your usage appears to have found a bug there. The order of the scripts shouldn't matter (that could cause other issues with other symptoms). So I think it would still be very useful if you can create a minimal reproducing testcase, we should investigate this.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dirk Vanden Boer]

Ok, the minimal test case I had was pretty minimal, so that's positive. I'll see if I can fully isolate it somewhere this weekend.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alon Zakai]

Great, thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dirk Vanden Boer]

My minimal reproduction scenario:

C++ source (asmerror.cpp):

#include <emscripten/bind.h>
#include <iostream>

static void hello() {
    std::cout << "Hello wasm\n";
}

EMSCRIPTEN_BINDINGS(asmerror) {
    emscripten::function("hello", &hello);
}

Html file generating the error:

<!doctype html>
<html>
    <head><meta charset="UTF-8"></head>
    <body>
        <script type="text/javascript" src="asmerror.js"></script>
        <script type="text/javascript">
          var Module = {
            print: function(text) { console.log(text); },
            printErr: function(text) { console.error(text); },
            onRuntimeInitialized: function() {
              console.log("onRuntimeInitialized");
              Module.hello();
            }
          };
        </script>
    </body>
</html>

Html file that works:

<!doctype html>
<html>
    <head><meta charset="UTF-8"></head>
    <body>
        <script type="text/javascript">
          var Module = {
            print: function(text) { console.log(text); },
            printErr: function(text) { console.error(text); },
            onRuntimeInitialized: function() {
              console.log("onRuntimeInitialized");
              Module.hello();
            }
          };
        </script>
        <script type="text/javascript" src="asmerror.js"></script>
    </body>
</html>

CMakeLists.txt file to create webassembly (emcmake cmake .):

cmake_minimum_required(VERSION 3.0)

project(asmerror)

set(CMAKE_CXX_STANDARD 11)

set(CMAKE_CXX_EXTENSIONS OFF)

find_program (EMCC emcc)

if (NOT EMCC)

    message(FATAL_ERROR "Could not find emcc executable")

endif ()

add_library(asmerror SHARED

    asmerror.cpp

)

set_target_properties(asmerror PROPERTIES SUFFIX .bc)

get_target_property(WASM_DIR asmerror ARCHIVE_OUTPUT_DIRECTORY)

get_target_property(WASM_MODULE asmerror OUTPUT_NAME)

add_custom_command(TARGET asmerror

                   POST_BUILD

                   COMMAND ${EMCC}

                   ARGS

                       -O3

                       -s WASM=1

                       -s TOTAL_MEMORY=96468992

                       -s DISABLE_EXCEPTION_CATCHING=0

                       -s ASSERTIONS=1

                       --llvm-lto 1

                       --bind

                       $<TARGET_FILE:asmerror>

                       -o $<TARGET_FILE_DIR:asmerror>/asmerror.js

                   BYPRODUCTS

                       ${CMAKE_BINARY_DIR}/asmerror.js

                       ${CMAKE_BINARY_DIR}/asmerror.wasm

                   COMMENT "Generating webassembly"

)

Hope this is clear

[Jukka Jylänki]

The Module object definitely needs to exist before including the main
.js file, otherwise the startup sequence won't connect to the right
object. I.e. the "Html file generating the error:" will not be
possible to work. I suppose changing to the working html file resolved
all the issues here(?)

> --
> 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.

[Dirk Vanden Boer]

Indeed, the working html file solved all the issues.

> email to emscripten-discuss+unsub...@googlegroups.com.

[Alon Zakai]

Thanks for the testcase, now I see. Yeah, it's indeed the order of those HTML elements. We should make this easier to debug, I opened

https://github.com/kripken/emscripten/pull/5595

with two improvements - first, to not capture Module unnecessarily in wasm startup (this just made debugging harder), and second, to explicitly check for Module being replaced, which is never valid to do, and can be caused by a bad order of elements. With that, this codebase would show an assertion failing with

"the Module object should not be replaced during async compilation - perhaps the order of HTML elements is wrong?"

> email to emscripten-discuss+unsubscribe@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.