Closed Bug 1243374 Opened 8 years ago Closed 8 years ago

Assertion failure: slotId == 0, at js/src/jit/arm/MoveEmitter-arm.cpp:208 with OOM

Categories

(Core :: JavaScript Engine, defect)

ARM
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla47
Tracking Status
firefox47 --- fixed

People

(Reporter: decoder, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:])

Attachments

(1 file)

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()>
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:bisect]
JSBugMon: Cannot process bug: Unable to automatically reproduce, please track manually.
Whiteboard: [jsbugmon:bisect] → [jsbugmon:]
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?
Flags: needinfo?(nicolas.b.pierron)
(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.
Flags: needinfo?(nicolas.b.pierron)
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
Attachment #8715298 - Flags: review?(nicolas.b.pierron) → review+
https://hg.mozilla.org/mozilla-central/rev/73e8c21d079a
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: