onRuntimeInitialized called on Chrome but not Safari

[stevedekorte]

This FAQ says Module.onRuntimeInitialized will be called when everything is ready:
https://emscripten.org/docs/getting_started/FAQ.html?highlight=onruntimeinitialized

This works for me on Chrome, but not on Safari.

My emscripten compiled&linked x.js file has the line:

if (Module["onRuntimeInitialized"]) Module["onRuntimeInitialized"]();

In Chrome, Module["onRuntimeInitialized"] returns the function I defined in the file that calls:

Module['onRuntimeInitialized'] = function () { console.log("got it!") }
import initModule from "./x.js";
initModule(Module)

But in Safari, Module["onRuntimeInitialized"] returns undefined.
I can manually edit the x.js file to call some other global function, but it would be nice if it worked as described in the FAQ.

My emcc version is:
% emcc -v
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.27 (afa75f3)
clang version 16.0.0 (https://github.com/llvm/llvm-project dee009d3b5c71a340eb4ebb3cfb49f6015a789cc)
Target: wasm32-unknown-emscripten
Thread model: posix

[sbc100]

That should certainly works the same in both cases.

How/where/when are you setting onRuntimeInitialized?

[stevedekorte]

I've put together a minimal demo project you can use to verify the bug:

https://github.com/stevedekorte/onRuntimeInitialized_test

You can test it using the repo's github pages site:

https://stevedekorte.github.io/onRuntimeInitialized_test/

For me, it works in:
Chrome Version 108.0.5359.98 (Official Build) (arm64)
but not:
Safari Version 16.0 (17614.1.25.9.10, 17614)
but are the latest releases as of today Dec 12, 2022

Both tested on the latest OSX 12.6 (21G115).

[kripken]

What happens on Firefox?

[stevedekorte]

It works on Firefox (108.0 (64-bit) on OSX 12.6 (21G115)). Note: you can click on this link to test it on any browser:

https://stevedekorte.github.io/onRuntimeInitialized_test/

If it prints "got onRuntimeInitialized call", it worked. Otherwise, it failed.

[kripken]

Thanks. Ok, hopefully someone with Apple hardware can try to confirm the problem on Safari. Worth seeing if there is anything odd in the dev console when it fails there.

If we can't figure this out then it would likely be a WebKit bug, and the right next step could be to open an issue there.

[stevedekorte]

Perhaps the way Module is defined could be simplified? It seems a bit complicated, at least to me.

[sbc100]

Yes, I also find it a little confusing/complicated. If we can find a way to simplify that would be great, but its most likely non-trivial due to so much history/legacy with in emscripten.. we don't want to break existing users if possible.

[stevedekorte]

This line in the emcc produced .js file seems to be problem:

  var Module = typeof Module != "undefined" ? Module : {};

This appears (on Safari) to silently overwrite the argument passed by "async function(Module)".
I'd suggest replacing:

async function(Module) {
  Module = Module || {};

  var Module = typeof Module != "undefined" ? Module : {};

with:

async function(Module = {}) {

This change works on the latest Safari, Chrome, Firefox, and Brave for me on the latest OSX.
For now, I can hack my build script to do this.

[sbc100]

Those sound like good ideas. There could be reason we don't do that already (IIRC that part of the codegen is already pretty complex), but certainly worth trying. @RReverser wdty?

[RReverser]

This appears (on Safari) to silently overwrite the argument passed by "async function(Module)".

Wat. How did Safari miss this? It's clearly a bug / a violation of JS spec :/

Out of curiousity, if you try an isolated example like this

(function foo(bar) { var bar=bar; console.log(bar) })(42)

what does it print in Safari?

But yeah, the suggested fix makes sense to me.

[sbc100]

(function foo(bar) { var bar=bar; console.log(bar) })(42) does print 42 on safari

[stevedekorte]

If I reduce my emcc compiled js file to:

var Module = (() => {
  var _scriptDir = import.meta.url;
  
  return (
    async function(Module) {
      console.log("Module 1:", Module);
      Module = Module || {};
      console.log("Module 2:", Module);
      var Module = typeof Module != "undefined" ? Module : {};
      console.log("Module 3:", Module);
      return Module.ready
    }
  );
})();
export default Module;

And my file which imports it to:

import initModule from "./test.js";
initModule({ foo: 42 });

the console log on Safari is:

[Log] Module 1: – undefined (test.js, line 7)
[Log] Module 2: – {} (test.js, line 9)
[Log] Module 3: – {} (test.js, line 11)

the console log on Chrome is:

iovm_test.js:7 Module 1: Object foo: 42[[Prototype]]: Object
iovm_test.js:9 Module 2: Object foo: 42[[Prototype]]: Object
iovm_test.js:11 Module 3: Object foo: 42[[Prototype]]: Object

So it looks like it's not even passing it in, but I suspect this a JS compilation bug where the local declaration is overwriting the argument when the stack frame is set up, as commenting out:

var Module = typeof Module != "undefined" ? Module : {};

solves the problem. I would have thought JS would provide a compiler warning (or error) if a local declaration conflicts with an argument.

[RReverser]

That's so weird... maybe it's async function specifically that has this bug? What if you try to remove it and make it a simple function?

[RReverser]

Too bad I don't have access to Safari, it'd be interesting to try and reduce this JS further.

[sbc100]

Is there some kind of compiler explorer thing but for JS engines?