1188301 - Crash [@ js::jit::MBasicBlock::insertAfter] with OOM

Status: RESOLVED DUPLICATE of bug 1193043

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision d3228c82badd (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --ion-offthread-compile=off --ion-eager):

let x = 3;
try {
    eval('let(z) { with({}) let y = 3; }');
} catch (ex) {
    (function(x) {
        return oomAfterAllocations(100)
    })(0 / 0)
}
testCatch(15);
function testCatch(y) {
    try {
        throw 5;
    } catch (ex) {
        (function() {
            assertEq(x + y + ex, 25);
        })(5)
    }
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
js::jit::MBasicBlock::insertAfter (this=0x7ffff69b1be8, at=0x7ffff69b2370, ins=0x0) at js/src/jit/MIRGraph.cpp:984
#0  js::jit::MBasicBlock::insertAfter (this=0x7ffff69b1be8, at=0x7ffff69b2370, ins=0x0) at js/src/jit/MIRGraph.cpp:984
#1  0x00000000009eac86 in js::jit::ObjectMemoryView::initStartingState (this=this@entry=0x7fffffffbeb0, pState=0x7fffffffbf60) at js/src/jit/ScalarReplacement.cpp:344
#2  0x0000000000a61eb5 in js::jit::EmulateStateOf<js::jit::ObjectMemoryView>::run (this=this@entry=0x7fffffffbf30, view=...) at js/src/jit/ScalarReplacement.cpp:53
#3  0x0000000000a1ed5c in js::jit::ScalarReplacement (mir=mir@entry=0x7ffff69b11a8, graph=...) at js/src/jit/ScalarReplacement.cpp:1266
#4  0x00000000009865d5 in js::jit::OptimizeMIR (mir=mir@entry=0x7ffff69b11a8) at js/src/jit/Ion.cpp:1372
#5  0x0000000000987855 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff69b11a8) at js/src/jit/Ion.cpp:1738
#6  0x000000000098f3e3 in js::jit::IonCompile (cx=cx@entry=0x7ffff6907000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x0, osrPc=<optimized out>, constructing=<optimized out>, recompile=<optimized out>, optimizationLevel=js::jit::Optimization_Normal) at js/src/jit/Ion.cpp:2077
#7  0x0000000000994b94 in js::jit::Compile (cx=cx@entry=0x7ffff6907000, script=..., script@entry=..., osrFrame=osrFrame@entry=0x0, osrPc=osrPc@entry=0x0, constructing=<optimized out>, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2236
#8  0x0000000000994dc6 in js::jit::CanEnter (cx=cx@entry=0x7ffff6907000, state=...) at js/src/jit/Ion.cpp:2390
#9  0x00000000006bbbc5 in js::RunScript (cx=cx@entry=0x7ffff6907000, state=...) at js/src/vm/Interpreter.cpp:637
#10 0x00000000006bc234 in js::Invoke (cx=cx@entry=0x7ffff6907000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:738
#11 0x00000000006bddc6 in js::Invoke (cx=cx@entry=0x7ffff6907000, thisv=..., fval=..., argc=argc@entry=1, argv=argv@entry=0x7fffffffceb0, rval=..., rval@entry=...) at js/src/vm/Interpreter.cpp:775
#12 0x00000000008e833a in js::jit::DoCallFallback (cx=0x7ffff6907000, frame=0x7fffffffcef8, stub_=<optimized out>, argc=<optimized out>, vp=0x7fffffffcea0, res=...) at js/src/jit/BaselineIC.cpp:9867
#13 0x00007ffff7feebdf in ?? ()
[...]
#37 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7fffffffbeb0	140737488338608
rcx	0x3	3
rdx	0x0	0
rsi	0x7ffff69b2370	140737330750320
rdi	0x7ffff69b1be8	140737330748392
rbp	0x7fffffffbd30	140737488338224
rsp	0x7fffffffbd10	140737488338192
r8	0x5	5
r9	0x7ffff69b2af8	140737330752248
r10	0x5e60	24160
r11	0x7ffff69b2038	140737330749496
r12	0x7ffff69b2370	140737330750320
r13	0x7ffff69b1be8	140737330748392
r14	0x7fffffffbeb0	140737488338608
r15	0x7ffff69b23c0	140737330750400
rip	0x9d1669 <js::jit::MBasicBlock::insertAfter(js::jit::MInstruction*, js::jit::MInstruction*)+25>
=> 0x9d1669 <js::jit::MBasicBlock::insertAfter(js::jit::MInstruction*, js::jit::MInstruction*)+25>:	mov    (%rdx),%rax
   0x9d166c <js::jit::MBasicBlock::insertAfter(js::jit::MInstruction*, js::jit::MInstruction*)+28>:	mov    %rdx,%rbx

Comment 1

[Benjamin Bouvier [:bbouvier] (inactive)]

Based on signature and stack trace, it's the same issue as bug 1193043.