Seems to be related to the simulateKeyEvent() code in the shell html.  Remove the call to this function fixes the crash.

I'm running the same version of Chrome on Linux, and don't get a crash (at least not immediately). Are there other repro steps/any flags?

I don't think so.  What does you console say?

I get the crash even with a fresh --user-data-dir

Ah, it's not actually compiling wasm due to a lack of mime type. Guess I need an actual HTTP server to run this (loading from file doesn't work because the fetch fails).

Oh.. you need to run with a server that serves the wasm mime type.

I normally run "./emrun <pathname>" form the emscripten checkout.

Somehow the_hole is being thrown (apparently by WebAssembly.instantiate) in the snippet (starting on line 1641):


    function instantiateArrayBuffer(receiver) {
      getBinaryPromise().then(function(binary) {
        return WebAssembly.instantiate(binary, info);
      }).then(receiver).catch(function(reason) {
        err('failed to asynchronously prepare wasm: ' + reason);
        abort(reason);
      });
    }

Investigating a bit further...

This doesn't reproduce on master. After bisecting, it was "fixed" (went from a crash to an exception) in herhut's 524215be1a29a23fcb44eee31ae98f1cac0c7746. But since that CL only claimed to be related to d8 ("Use new arraybuffer deleter interface in d8"), assigning to him to make sure that the new behavior is correct.

Yes, so I meant to say I didn't a little investigation and found that the issue was trying to call instantiateArrayBuffer from the catch handle when the streaming instantiate fails.  

I fixed the faulting error handling in emscripten so it was doubly fixed I hope:
https://github.com/kripken/emscripten/commit/d59e3c5360cf1803b2661893fc0ef3c416928039

I looked now as well and the underlying bug was actually fixed in 175f2a6a6cabbfb9498dab82b27e45e54438a5d1. The issue was that we did not throw an exception in some cases where instantiation failed, ending up with an empty instance object but no exception.