The following testcase crashes on mozilla-central revision c0ba5835ca48 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --target=i686-pc-linux-gnu --disable-tests --enable-simulator=arm --enable-debug, run with --fuzzing-safe --no-threads --ion-eager --arm-asm-nop-fill=1 --arm-hwcap=vfp): m = parseModule(` enableSPSProfiling(); oomTest(function() eval("")); `); m.declarationInstantiation(); m.evaluation(); Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x084b0332 in js::jit::MoveEmitterARM::completeCycle (this=this@entry=0xffff9d34, from=..., to=..., type=js::jit::MoveOp::GENERAL, slotId=1) at js/src/jit/arm/MoveEmitter-arm.cpp:208 #0 0x084b0332 in js::jit::MoveEmitterARM::completeCycle (this=this@entry=0xffff9d34, from=..., to=..., type=js::jit::MoveOp::GENERAL, slotId=1) at js/src/jit/arm/MoveEmitter-arm.cpp:208 #1 0x084b14dc in js::jit::MoveEmitterARM::emit (this=this@entry=0xffff9d34, move=...) at js/src/jit/arm/MoveEmitter-arm.cpp:364 #2 0x084b15f8 in js::jit::MoveEmitterARM::emit (this=this@entry=0xffff9d34, moves=...) at js/src/jit/arm/MoveEmitter-arm.cpp:35 #3 0x08272b82 in js::jit::CodeGenerator::visitMoveGroup (this=0xf61fb000, group=<optimized out>) at js/src/jit/CodeGenerator.cpp:2482 #4 0x0835e816 in js::jit::LMoveGroup::accept (this=0xf61f82f8, visitor=0xf61fb000) at js/src/jit/shared/LIR-shared.h:116 #5 0x082a5b6b in js::jit::CodeGenerator::generateBody (this=this@entry=0xf61fb000) at js/src/jit/CodeGenerator.cpp:4447 #6 0x082a64d3 in js::jit::CodeGenerator::generate (this=this@entry=0xf61fb000) at js/src/jit/CodeGenerator.cpp:8170 #7 0x082bd644 in js::jit::GenerateCode (mir=mir@entry=0xf61f3100, lir=0xf61f47d8) at js/src/jit/Ion.cpp:1993 #8 0x082c6546 in js::jit::CompileBackEnd (mir=mir@entry=0xf61f3100) at js/src/jit/Ion.cpp:2015 #9 0x082c9cac in js::jit::IonCompile (cx=cx@entry=0xf7a70020, script=script@entry=0xf636c0d0, baselineFrame=baselineFrame@entry=0x0, osrPc=osrPc@entry=0x0, constructing=constructing@entry=false, recompile=recompile@entry=false, optimizationLevel=js::jit::Normal) at js/src/jit/Ion.cpp:2279 #10 0x082ca501 in js::jit::Compile (cx=cx@entry=0xf7a70020, script=script@entry=..., osrFrame=osrFrame@entry=0x0, osrPc=osrPc@entry=0x0, constructing=false, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2449 #11 0x082ca6d0 in js::jit::CanEnter (cx=cx@entry=0xf7a70020, state=...) at js/src/jit/Ion.cpp:2541 #12 0x08679f8d in js::RunScript (cx=cx@entry=0xf7a70020, state=...) at js/src/vm/Interpreter.cpp:401 #13 0x0867a2ce in js::Invoke (cx=0xf7a70020, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:493 #14 0x0867ad9e in js::Invoke (cx=cx@entry=0xf7a70020, thisv=..., fval=..., argc=argc@entry=0, argv=argv@entry=0x0, rval=rval@entry=...) at js/src/vm/Interpreter.cpp:527 #15 0x084d4538 in JS_CallFunction (cx=cx@entry=0xf7a70020, obj=..., fun=fun@entry=..., args=..., rval=rval@entry=...) at js/src/jsapi.cpp:2848 #16 0x086a386a in OOMTest (cx=0xf7a70020, argc=1, vp=0xffffa620) at js/src/builtin/TestingFunctions.cpp:1203 [...] #31 0x0867bc42 in js::Execute (cx=cx@entry=0xf7a70020, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0xffffb210) at js/src/vm/Interpreter.cpp:713 #32 0x0848cd45 in js::ModuleObject::evaluate (cx=cx@entry=0xf7a70020, self=..., self@entry=..., rval=rval@entry=...) at js/src/builtin/ModuleObject.cpp:824 #33 0x08720dbb in intrinsic_EvaluateModule (cx=0xf7a70020, argc=1, vp=0xffffb210) at js/src/vm/SelfHosting.cpp:1540 #34 0x0867d2aa in js::CallJSNative (cx=0xf7a70020, native=0x8720d50 <intrinsic_EvaluateModule(JSContext*, unsigned int, JS::Value*)>, args=...) at js/src/jscntxtinlines.h:235 [...] #67 main (argc=7, argv=0xffffcbb4, envp=0xffffcbd4) at js/src/shell/js.cpp:6999 eax 0x0 0 ebx 0x9810158 159449432 ecx 0xf7e3b88c -136071028 edx 0x0 0 esi 0xf61fb41c -165694436 edi 0xffff9d34 -25292 ebp 0xffff9c78 4294941816 esp 0xffff9c20 4294941728 eip 0x84b0332 <js::jit::MoveEmitterARM::completeCycle(js::jit::MoveOperand const&, js::jit::MoveOperand const&, js::jit::MoveOp::Type, unsigned int)+1314> => 0x84b0332 <js::jit::MoveEmitterARM::completeCycle(js::jit::MoveOperand const&, js::jit::MoveOperand const&, js::jit::MoveOp::Type, unsigned int)+1314>: movl $0xd0,0x0 0x84b033c <js::jit::MoveEmitterARM::completeCycle(js::jit::MoveOperand const&, js::jit::MoveOperand const&, js::jit::MoveOp::Type, unsigned int)+1324>: call 0x80f8560 <abort()>

JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.

Nicolas, you've added this assertion: if the MoveResolver has oom'd and returned early, would it make sense that the MoveOp could be malformed? I could imagine this happening in MoveResolver::resolve(), as we may miss the call to MoveOp::setCycleEnd() if we returned false from the call to addOrderedMove(). In this case, is the fix to this to *not* call MoveEmitter::emit if the masm has oom'd?

(In reply to Benjamin Bouvier [:bbouvier] from comment #2) > Nicolas, you've added this assertion This assertion comes from Bug 991153, I only converted it to a MOZ_ASSERT. > if the MoveResolver has oom'd and > returned early, would it make sense that the MoveOp could be malformed? I > could imagine this happening in MoveResolver::resolve(), as we may miss the > call to MoveOp::setCycleEnd() if we returned false from the call to > addOrderedMove(). In this case, is the fix to this to *not* call > MoveEmitter::emit if the masm has oom'd? Other code path which are using the MoveResolver are skipping the remains of the function if an oom happened in the MoveResolver, I suggest we follow the same pattern in visitMoveGroup.

Review commit: https://reviewboard.mozilla.org/r/33377/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/33377/

Comment on attachment 8715298 [details] MozReview Request: Bug 1243374: Don't emit moves if the MoveResolver has failed earlier; r?nbp https://reviewboard.mozilla.org/r/33377/#review30101