Re: Firefox: Module.asm is undefined

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

Re: Firefox: Module.asm is undefined

Indeed, the working html file solved all the issues. On Monday, September 18, 2017 at 2:55:24 PM UTC+2, jj wrote: > > 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

Re: Firefox: Module.asm is undefined

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(?)

Re: Firefox: Module.asm is undefined

My minimal reproduction scenario: C++ source (asmerror.cpp): #include #include static void hello() { std::cout << "Hello wasm\n"; } EMSCRIPTEN_BINDINGS(asmerror) { emscripten::function("hello", ); } Html file generating the error: var Module =

Re: Firefox: Module.asm is undefined

Great, thanks. On Fri, Sep 15, 2017 at 9:58 AM, Dirk Vanden Boer wrote: > 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. > > On Friday, September 15, 2017 at 6:55:46 PM UTC+2, Alon Zakai

Re: Firefox: Module.asm is undefined

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

Re: Firefox: Module.asm is undefined

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. On Friday, September 15, 2017 at 6:55:46 PM UTC+2, Alon Zakai wrote: > > Hmm, I still don't understand this. In particular, when ASSERTIONS is on, > you should

Re: Firefox: Module.asm is undefined

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

Re: Firefox: Module.asm is undefined

Alright, I'll try to simplify the program tomorrow and get back to you. On Thursday, September 14, 2017 at 10:04:02 PM UTC+2, Alon Zakai wrote: > > 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 >

Re: Firefox: Module.asm is undefined

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.). On Thu, Sep 14, 2017 at 12:50 PM, Dirk Vanden

Re: Firefox: Module.asm is undefined

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:

Re: Firefox: Module.asm is undefined

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