var module = new WebAssembly.Module(wasmTextToBinary('\
  (memory 1) \
  (export "store" (func $func0)) \
  (func $func0 \
    (param $var0 i32) \
    (param $var1 i64) \
    local.get $var0 \
    local.get $var1 \
    i64.store16 offset=16 \
  ) \
'));
for (let i = 0; i < 10; i++) {
  try {
    for (let i = 0; i < 1; i++) {
      x = new WebAssembly.Instance(module);
    }
    for (let i = 0; i < 1; i++) {};
    x.exports["store"]();
  } catch (e) {}
}

Compiled using GCC 9.3.0 and Clang 9 with:

'CC="clang -m32 -msse2 -mfpmath=sse"' PKG_CONFIG_PATH=<path to your>/pkgconfig AR=ar 'CXX="clang++ -m32 -msse2 -mfpmath=sse"' sh ./configure --target=i686-pc-linux --enable-debug --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

Run with:

--fuzzing-safe --no-threads --no-baseline --no-ion

Tested on m-c rev d51942b1e2d8. This seems 32-bit only.

Will try to get a bisect soon. I did not set any Cranelift flags. Weird memory addresses are on the stack so setting s-s and sec-bounty? as a start.

:bbouvier seems afk (according to status), so setting needinfo? from :cfallin and :lth prior to the bisection result.

Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) x/i $pc
=> 0x58f4e9b6 <CoerceInPlace_JitEntry(int, js::wasm::TlsData*, JS::Value*)+38>:	mov    0x8(%esi),%ecx
(gdb) x/b $esi
0xffffff8c:	Cannot access memory at address 0xffffff8c
(gdb) x/b $ecx
0xedc6a380:	0xf8
(gdb)

On Linux, does this mean in the $pc, we are trying to access memory address 0xffffff8c ?

Also found internally.

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/95d6c42f07fd
user:        Dmitry Bezhetskov
date:        Thu Aug 06 07:41:50 2020 +0000
summary:     Bug 1639153 - Part 1: Reserve two slots after stack arguments for the future tls preservation. r=lth

Dmitry, is bug 1639153 a likely regressor?

(Clearing needinfo? for :cfallin, this is not likely to involve Cranelift)

(In reply to Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now) from comment #3)

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/95d6c42f07fd
user:        Dmitry Bezhetskov
date:        Thu Aug 06 07:41:50 2020 +0000
summary:     Bug 1639153 - Part 1: Reserve two slots after stack arguments for the future tls preservation. r=lth

Dmitry, is bug 1639153 a likely regressor?

(Clearing needinfo? for :cfallin, this is not likely to involve Cranelift)

Yeah, that's my guess too, and I can try to verify, I've just had to finish up a different patch stack first...

This affects Windows 10 too, but is 32-bit only.

(In reply to Lars T Hansen [:lth] from comment #4)

Yeah, that's my guess too, and I can try to verify, I've just had to finish up a different patch stack first...

Thanks Lars!

Backing out Dmitry's changes removes the crash.

The changes are being backed out from central, they caused a lot of problems.

Split bounty with bug 1657815 under the old rules, although clearly we would have fixed this one regardless based on the tons of other regressions not filed as security bugs. Under the new rules this bug would not have earned a bounty because all the collisions happened within the 4-day exclusion window from when the regressing bug landed.