The following testcase crashes on mozilla-central revision ebad93e11770 (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu --enable-simulator=arm, run with --fuzzing-safe --thread-count=2 --baseline-eager --ion-eager --ion-extra-checks --ion-aa=flow-sensitive --ion-offthread-compile=off): loadFile(` function f() { for (var i = 0; i < 100; i++) {} var x = new Foo("++\\u0041"); } assertEq(f().target , "cats"); `); function loadFile(lfVarx) { oomTest(function() { eval(lfVarx); }); } Backtrace: received signal SIGSEGV, Segmentation fault. 0x083f11a9 in js::jit::MoveResolver::PendingMove::setCycleEnd (this=<optimized out>, this=<optimized out>, cycleSlot=<optimized out>) at js/src/jit/MoveResolver.h:285 #0 0x083f11a9 in js::jit::MoveResolver::PendingMove::setCycleEnd (this=<optimized out>, this=<optimized out>, cycleSlot=<optimized out>) at js/src/jit/MoveResolver.h:285 #1 js::jit::MoveResolver::resolve (this=0xf4cca36c) at js/src/jit/MoveResolver.cpp:266 #2 0x0823aa7b in js::jit::CodeGenerator::visitMoveGroup (this=0xf4cca000, group=0xf4d9b978) at js/src/jit/CodeGenerator.cpp:3077 #3 0x08352aaa in js::jit::LMoveGroup::accept (this=0xf4d9b978, visitor=0xf4cca000) at js/src/jit/shared/LIR-shared.h:116 #4 0x0828f6e7 in js::jit::CodeGenerator::generateBody (this=0xf4cca000) at js/src/jit/CodeGenerator.cpp:5394 #5 0x082902d2 in js::jit::CodeGenerator::generate (this=0xf4cca000) at js/src/jit/CodeGenerator.cpp:9767 #6 0x082aab9c in js::jit::GenerateCode (mir=0xf4d950f8, lir=0xf4d97950) at js/src/jit/Ion.cpp:1944 #7 0x083091ef in js::jit::CompileBackEnd (mir=0xf4d950f8) at js/src/jit/Ion.cpp:1966 #8 0x0807338b in js::jit::IonCompile (cx=cx@entry=0xf791d000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x0, osrPc=0x0, recompile=false, optimizationLevel=js::jit::OptimizationLevel::Normal) at js/src/jit/Ion.cpp:2247 #9 0x0830970d in js::jit::Compile (cx=cx@entry=0xf791d000, script=script@entry=..., osrFrame=osrFrame@entry=0x0, osrPc=0x0, forceRecompile=false) at js/src/jit/Ion.cpp:2440 #10 0x08309890 in js::jit::CanEnter (cx=0xf791d000, state=...) at js/src/jit/Ion.cpp:2537 #11 0x081697c7 in js::RunScript (cx=0xf791d000, state=...) at js/src/vm/Interpreter.cpp:386 #12 0x08169c38 in js::InternalCallOrConstruct (cx=0xf791d000, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:488 #13 0x08169f1f in InternalCall (cx=cx@entry=0xf791d000, args=...) at js/src/vm/Interpreter.cpp:515 #14 0x0816a07f in js::CallFromStack (cx=0xf791d000, args=...) at js/src/vm/Interpreter.cpp:521 #15 0x0822e33f in js::jit::DoCallFallback (cx=0xf791d000, frame=0xf61ffb68, stub_=0xf4cd7090, argc=0, vp=0xf61ffb28, res=...) at js/src/jit/BaselineIC.cpp:2455 [...] #22 0x0820d822 in EnterBaseline (cx=cx@entry=0xf791d000, data=...) at js/src/jit/BaselineJIT.cpp:162 #23 0x082275bd in js::jit::EnterBaselineMethod (cx=0xf791d000, state=...) at js/src/jit/BaselineJIT.cpp:200 #24 0x08169912 in js::RunScript (cx=0xf791d000, state=...) at js/src/vm/Interpreter.cpp:400 #25 0x0816be68 in js::ExecuteKernel (cx=0xf791d000, script=..., envChainArg=..., newTargetValue=..., evalInFrame=..., result=0xf61ffc30) at js/src/vm/Interpreter.cpp:699 #26 0x0819aea6 in EvalKernel (cx=cx@entry=0xf791d000, v=..., v@entry=..., evalType=evalType@entry=DIRECT_EVAL, caller=..., env=..., pc=0xf5d8bae5 "{", vp=...) at js/src/builtin/Eval.cpp:328 #27 0x0819b3a7 in js::DirectEval (cx=0xf791d000, v=..., vp=...) at js/src/builtin/Eval.cpp:438 #28 0x0822e648 in js::jit::DoCallFallback (cx=0xf791d000, frame=0xf61ffc98, stub_=0xf79ad0b0, argc=1, vp=0xf61ffc58, res=...) at js/src/jit/BaselineIC.cpp:2439 [...] #39 0x08169f1f in InternalCall (cx=cx@entry=0xf791d000, args=...) at js/src/vm/Interpreter.cpp:515 #40 0x0816a0ba in js::Call (cx=0xf791d000, fval=..., thisv=..., args=..., rval=...) at js/src/vm/Interpreter.cpp:534 #41 0x08550bce in JS_CallFunction (cx=0xf791d000, obj=..., fun=..., args=..., rval=...) at js/src/jsapi.cpp:2850 #42 0x0846dea9 in OOMTest (cx=0xf791d000, argc=1, vp=0xf61ffd90) at js/src/builtin/TestingFunctions.cpp:1541 #43 0x08173eb6 in js::CallJSNative (cx=0xf791d000, native=0x846dae0 <OOMTest(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:293 #44 0x08169b13 in js::InternalCallOrConstruct (cx=0xf791d000, args=..., construct=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:470 [...] #77 Shell (envp=<optimized out>, op=0xffffcb90, cx=<optimized out>) at js/src/shell/js.cpp:8068 #78 main (argc=9, argv=0xffffcd14, envp=0xffffcd3c) at js/src/shell/js.cpp:8464 eax 0x0 0 ebx 0xf4d9bc18 -187057128 ecx 0xf7da4864 -136689564 edx 0x0 0 esi 0xf4d9bc18 -187057128 edi 0xffff9824 -26588 ebp 0xffff9858 4294940760 esp 0xffff97d0 4294940624 eip 0x83f11a9 <js::jit::MoveResolver::resolve()+1961> => 0x83f11a9 <js::jit::MoveResolver::resolve()+1961>: movl $0x0,0x0 0x83f11b3 <js::jit::MoveResolver::resolve()+1971>: ud2

NI Sean because he fixed a similar assertion failure recently.

autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/b7adf3986079 user: Sander Mathijs van Veen date: Tue Feb 07 07:18:00 2017 +0100 summary: Bug 1337367 - Postpone spilling bundles till after regalloc main loop r=bhackett Probably related to bug 1337367?

Unfortunately this is a different kind of failure than the one I fixed. Bug 1337367 does seem like a likely culprit. The MoveGroup in question is the following: > From: [reg 1], To: [reg 0] > From: [reg 1], To: [reg 0] > From: [reg 0], To: [reg 1] The problem is that there is a duplicate PendingMove in the list. It blows up because both of the first two PendingMoves conflict in the cycle with the third one. It's possible that this scenario occurs much more frequently. We could catch it by checking for duplicate PendingMoves in DEBUG builds.

Backing out bug 1337367 does fix this assertion.

I've added related security bugs as to the bug block list. I think it has more to do with a structural problem in the ARM move resolver (https://bugzilla.mozilla.org/show_bug.cgi?id=1337967#c8), and the patch in bug 1337367 shows the problem while it was hidden before by spilling. I'm currently not able to work on it unfortunately.

JSBugMon: The testcase found in this bug no longer reproduces (tried revision f650c0df72f9).

autobisectjs shows this is probably related to the following changeset: The first good revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/ef7430b93e7c user: Sean Stangl date: Tue May 15 15:16:00 2018 +0300 summary: Bug 1456524 - Maintain MoveResolver invariants. r=jandem Sean, is bug 1456524 a likely fix?

Iain, with your recent work on OOM in SpiderMonkey, do you think bug 1456524 is a likely fix?

Bug 1456524 is definitely the fix. Closing as duplicate.