Thanks for filing the issue!

Unable to reproduce the issue on reported chrome version 70.0.3538.77 and on the latest stable 71.0.3578.98 using Ubuntu 17.10 with the below mentioned steps.
1. Launched Chrome
2. Navigated to https://tbfleming.github.io/cib/
3. Clicked compile from the bottom left panel and then clicked run from the bottom right panel.
In the process we didn't observe any crash. Attaching the screenshots of the same for reference.

@Reporter: Could you please let us know if we have missed anything in the process. Requesting you to check the same in a new profile without any apps & extensions and let us know if the issue still persists.

Deleted: 922207_M71.png 167 KB

	922207_M71.png 167 KB View Download

Deleted: 922207_M70.png 158 KB

	922207_M70.png 158 KB View Download

attach my screenshot,

even you didn't reproduce the crash,

the memory access out of bound issue is also a regression, didn't see it with < 69

but I'm not sure whose fault that is. 

Deleted: Selection_033.png 105 KB

	Selection_033.png 105 KB View Download

Deleted: Selection_034.png 23.6 KB

	Selection_034.png 23.6 KB View Download

Deleted: Selection_035.png 14.5 KB

	Selection_035.png 14.5 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

the c++ code itself looks legit. but when it is compiled into wasm, it caused the out of bound error.

interestingly, people saw the out of bound issue with newer firefox too, so the issue could be the wasm/clang toolchain.

but I didn't seem to see any recent updates to the toolchain used in that project.

and this code works fine with my older firefox:

Deleted: Selection_036.png 108 KB

	Selection_036.png 108 KB View Download

Bisected in Windows 7 to r566745 "Update V8"
https://chromium.googlesource.com/v8/v8/+log/3f7f40e7..a0f86882

There are two wasm-related changes:
7ce76fbc340e61dc0021ef497bf6bb6cecda20e0 [wasm] Enable mutable-global by default
da03262e4c0fb58af1d25c4336506f2477bfd188 [wasm] Fix for exporting imported mutable globals

Landed in 69.0.3460.0

Thanks @woxxom...

Somehow couldn't reproduce the issue on Windows 7 too from our end, as per comment#6....assigning it to "Ben Smith" from https://chromium.googlesource.com/v8/v8/+log/3f7f40e7..a0f86882
Note: From C#6 adding OS Windows.

@Ben Smith: Please help in re-assigning it to the right owner if this isn't related to your change.

I get a runtime error: memory access out of bounds, i.e. it does not crash the browser. It is likely that enabling mutable globals exercises a different path in the generated Emscripten code, and thus is likely a toolchain issue. Messing with the demo, if I comment out the constructor of the "struct S", it no longer crashes. So maybe cout does not work before main can be called.

Maybe Alon can help.

@billconan - what happens when the user presses "Run"? I am guessing it has some custom JS to load the compiled wasm, which is not emitted by emscripten, since you just run clang in the browser in this demo (and not the rest of the emscripten compiler)?

If so, then perhaps the issue is how that code handles exported globals. This was a breaking change in wasm, see e.g. how emscripten handles it here:

https://github.com/emscripten-core/emscripten/blob/incoming/src/support.js#L479

  if (typeof value === 'object') {
    // a breaking change in the wasm spec, globals are now objects
    // https://github.com/WebAssembly/mutable-global/issues/1
    value = value.value;
  }

(see also the discussion in that quoted link to the mutable-global project)

If your custom JS doesn't handle exported globals in the new way, it may get an export from the wasm and get a zero instead of the actual value, so it might then end up calling the wrong code or something else later.

However, reading

https://github.com/tbfleming/cib/blob/master/src/process-runtime.js

(is that the right place?) I don't see it depend on exported globals, but maybe I'm missing something?