bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Assertion failure: !cycleEnd_, at js/src/jit/MoveResolver.h:285 with OOM




JavaScript Engine
10 months ago
8 months ago


(Reporter: decoder, Unassigned, NeedInfo)


(Blocks: 2 bugs, {assertion, jsbugmon, testcase})

assertion, jsbugmon, testcase
Dependency tree / graph

Firefox Tracking Flags

(firefox55 affected)


(Whiteboard: [jsbugmon:update])



10 months ago
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):

  function f() {
    for (var i = 0; i < 100; i++) {}
    var x = new Foo("++\\u0041");
  assertEq(f().target , "cats");
function loadFile(lfVarx) {
    oomTest(function() {


 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

Comment 1

10 months ago
NI Sean because he fixed a similar assertion failure recently.
Flags: needinfo?(sstangl)
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?
Blocks: 1337367
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]

Comment 3

10 months ago
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.
Flags: needinfo?(sstangl) → needinfo?(bhackett1024)
Backing out bug 1337367 does fix this assertion.
Flags: needinfo?(bhackett1024) → needinfo?(sandervv)


8 months ago
Flags: needinfo?(sandervv)
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.
Flags: needinfo?(bhackett1024)
You need to log in before you can comment on or make changes to this bug.