The following testcase crashes on mozilla-central revision 49b2a4c8be01 (build with --enable-debug --enable-simulator=arm64, run with --fuzzing-safe --no-threads --ion-eager):

setJitCompilerOption('ion.enable', 1);
function m(f, z) {
    for (let j = 0; j < 29; ++j) {
        for (let k = 0; k < 9; ++k) {
            try {
                f(z[j], z[k]);
            } catch (e) {}
        }
    }
}
function g(x, y) {
    y ? undefined : undefined;
    y ? Math.imul(+x, !(0. | 0) | 0) : y;
    x();
}
m(g, [Number.MAX_SAFE_INTEGER]);

(no backtrace available)

For detailed crash information, see attachment.

:sstangl mentioned in-person that since the testcase turns on IonMonkey and this involves the ARM64 simulator, it should be opened up for now.

The unreduced form of this testcase had crashed opt shell [@ JSObject::getClass].

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/4c7b508eb10d
user: Nicolas B. Pierron
date: Fri Feb 15 14:29:43 2019 +0000
summary: Bug 1526959 - ARM64 Simulator: Clobber volatile registers on VM function calls. r=sstangl

:nbp, is bug 1526959 a likely regressor?

(In reply to Gary Kwong [:gkw] [:nth10sd] - gradually taking PTO-ish till Mar 11 from comment #3)

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/4c7b508eb10d
summary: Bug 1526959 - ARM64 Simulator: Clobber volatile registers on VM function calls. r=sstangl

:nbp, is bug 1526959 a likely regressor?

No, but you might be able to get a better regression range on an ARM64 device or by back-porting this patch on the simulator.

This patch is clobbering every volatile register except the returned value register to emulate what would happen on ARM64 device when a call into C++ code clobber the content of these registers.

autobisectjs shows this is probably related to the following changeset:

The first bad revision is:
changeset: https://hg.mozilla.org/mozilla-central/rev/1b9f4cb229fa
user: Sean Stangl
date: Tue Feb 12 13:02:01 2019 +0000
summary: Bug 1523015 - Summary: Enable Ion on ARM64, but disable in-browser by pref. r=nbp

I bisected on a native ARM64 VM and got this, so it blocking the main ARM64 IonMonkey bug for fuzzbugs should be correct.

(In reply to Gary Kwong [:gkw] [:nth10sd] - gradually taking PTO-ish till Mar 11 from comment #5)

summary: Bug 1523015 - Summary: Enable Ion on ARM64, but disable in-browser by pref. r=nbp

I bisected on a native ARM64 VM and got this, so it blocking the main ARM64 IonMonkey bug for fuzzbugs should be correct.

This is unlikely to be that bug, but bisecting previous revision might not catch the right issue either.
Thanks.

Steven, can you have please someone look into this for possible fix in 67 (soft freeze on Mar 11)?

Nicolas, I saw you were looking at this bug last week. Any updates on it? I am assuming this is part of the fuzz bugs we need to fix for ARM64 support in Ion.

(In reply to Steven DeTar [:sdetar] from comment #9)

Nicolas, I saw you were looking at this bug last week. Any updates on it? I am assuming this is part of the fuzz bugs we need to fix for ARM64 support in Ion.

I have not investigated this bug yet, just answered Gary while triaging.
Yes, this is part of the fuzz bugs we have on ARM64 IonMonkey.

(In reply to Neha Kochar [:neha] from comment #8)

Steven, can you have please someone look into this for possible fix in 67 (soft freeze on Mar 11)?

This is an ARM64 Simulator issue (not x64), blocking Bug 1529669. This is part of the bucket of bugs we are going to look at next.
However, it is unlikely that all of them are going to be fixed by March 11.

Sean or my self should look at this bug for fixing ARM64 issue.

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

After testing, I confirm this is a duplicate of bug 1534810.