1269756 - Assertion failure: tagCount > 0, at js/src/jit/CodeGenerator.cpp:531 with OOM

Status: RESOLVED DUPLICATE of bug 1264948

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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

oomTest(function() {
    m = parseModule(`while (x && NaN) prototype; let x`);
    m.declarationInstantiation();
    m.evaluation();
})



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000669979 in js::jit::CodeGenerator::testValueTruthyKernel (this=this@entry=0x7ffff335e000, value=..., scratch1=scratch1@entry=0x7ffff3338248, scratch2=scratch2@entry=0x7ffff3338258, fr=..., fr@entry=..., ifTruthy=ifTruthy@entry=0x7ffff33379d0, ifFalsy=ifFalsy@entry=0x7ffff3337990, ool=ool@entry=0x0, valueMIR=valueMIR@entry=0x7ffff3336a50) at js/src/jit/CodeGenerator.cpp:531
#0  0x0000000000669979 in js::jit::CodeGenerator::testValueTruthyKernel (this=this@entry=0x7ffff335e000, value=..., scratch1=scratch1@entry=0x7ffff3338248, scratch2=scratch2@entry=0x7ffff3338258, fr=..., fr@entry=..., ifTruthy=ifTruthy@entry=0x7ffff33379d0, ifFalsy=ifFalsy@entry=0x7ffff3337990, ool=ool@entry=0x0, valueMIR=valueMIR@entry=0x7ffff3336a50) at js/src/jit/CodeGenerator.cpp:531
#1  0x0000000000669f31 in testValueTruthy (valueMIR=0x7ffff3336a50, ool=0x0, ifFalsy=0x7ffff3337990, ifTruthy=0x7ffff33379d0, fr=..., scratch2=0x7ffff3338258, scratch1=0x7ffff3338248, value=..., this=0x7ffff335e000) at js/src/jit/CodeGenerator.cpp:649
#2  js::jit::CodeGenerator::visitTestVAndBranch (this=0x7ffff335e000, lir=0x7ffff33381e0) at js/src/jit/CodeGenerator.cpp:721
#3  0x000000000067a7bc in js::jit::CodeGenerator::generateBody (this=this@entry=0x7ffff335e000) at js/src/jit/CodeGenerator.cpp:5030
#4  0x000000000067b23a in js::jit::CodeGenerator::generate (this=this@entry=0x7ffff335e000) at js/src/jit/CodeGenerator.cpp:8865
#5  0x00000000006a2a95 in js::jit::GenerateCode (mir=mir@entry=0x7ffff33321c0, lir=0x7ffff33374a8) at js/src/jit/Ion.cpp:1959
#6  0x0000000000704c63 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff33321c0) at js/src/jit/Ion.cpp:1981
#7  0x000000000070576b in js::jit::IonCompile (cx=cx@entry=0x7ffff6908c00, script=script@entry=0x7ffff7eaf3d0, baselineFrame=baselineFrame@entry=0x0, osrPc=<optimized out>, constructing=<optimized out>, recompile=<optimized out>, optimizationLevel=optimizationLevel@entry=js::jit::Normal) at js/src/jit/Ion.cpp:2241
#8  0x0000000000705e6c in js::jit::Compile (cx=cx@entry=0x7ffff6908c00, script=..., script@entry=..., osrFrame=osrFrame@entry=0x0, osrPc=osrPc@entry=0x0, constructing=<optimized out>, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2408
#9  0x000000000070608e in js::jit::CanEnter (cx=cx@entry=0x7ffff6908c00, state=...) at js/src/jit/Ion.cpp:2500
#10 0x0000000000aaf3b9 in js::RunScript (cx=0x7ffff6908c00, state=...) at js/src/vm/Interpreter.cpp:402
#11 0x0000000000ab132b in js::ExecuteKernel (cx=0x7ffff6908c00, script=..., script@entry=..., scopeChainArg=..., newTargetValue=..., evalInFrame=..., evalInFrame@entry=..., result=result@entry=0x7fffffffbd08) at js/src/vm/Interpreter.cpp:704
#12 0x0000000000ab1607 in js::Execute (cx=cx@entry=0x7ffff6908c00, script=script@entry=..., scopeChainArg=..., rval=rval@entry=0x7fffffffbd08) at js/src/vm/Interpreter.cpp:737
#13 0x000000000082c951 in js::ModuleObject::evaluate (cx=cx@entry=0x7ffff6908c00, self=..., self@entry=..., rval=rval@entry=...) at js/src/builtin/ModuleObject.cpp:896
#14 0x0000000000afff71 in intrinsic_EvaluateModule (cx=0x7ffff6908c00, argc=<optimized out>, vp=0x7fffffffbd08) at js/src/vm/SelfHosting.cpp:2119
#15 0x00007ffff7fcc606 in ?? ()
#16 0x00007fffffffbd10 in ?? ()
#17 0x00007fffffffbce0 in ?? ()
#18 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x0	0
rcx	0x7ffff6ca588d	140737333844109
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7fffffffb3b0	140737488335792
rsp	0x7fffffffb2b0	140737488335536
r8	0x7ffff7fdf7c0	140737354004416
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7fffffffb070	140737488334960
r11	0x7ffff6c27ee0	140737333329632
r12	0x7ffff3336a50	140737273621072
r13	0x7ffff335e000	140737273782272
r14	0x0	0
r15	0x7fffffffb3f0	140737488335856
rip	0x669979 <js::jit::CodeGenerator::testValueTruthyKernel(js::jit::ValueOperand const&, js::jit::LDefinition const*, js::jit::LDefinition const*, js::jit::FloatRegister, js::jit::Label*, js::jit::Label*, js::jit::OutOfLineTestObject*, js::jit::MDefinition*)+1913>
=> 0x669979 <js::jit::CodeGenerator::testValueTruthyKernel(js::jit::ValueOperand const&, js::jit::LDefinition const*, js::jit::LDefinition const*, js::jit::FloatRegister, js::jit::Label*, js::jit::Label*, js::jit::OutOfLineTestObject*, js::jit::MDefinition*)+1913>:	movl   $0x213,0x0
   0x669984 <js::jit::CodeGenerator::testValueTruthyKernel(js::jit::ValueOperand const&, js::jit::LDefinition const*, js::jit::LDefinition const*, js::jit::FloatRegister, js::jit::Label*, js::jit::Label*, js::jit::OutOfLineTestObject*, js::jit::MDefinition*)+1924>:	callq  0x4b07b0 <abort()>

Comment 1

[Fuzzing Team]

JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20160105064937" and the hash "f18072a8592581df42c0be4f669151334757565c".
The "bad" changeset has the timestamp "20160105073330" and the hash "a110885c2b5b808c78cb695a2202d481dcb559fb".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f18072a8592581df42c0be4f669151334757565c&tochange=a110885c2b5b808c78cb695a2202d481dcb559fb

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: OOM_VERBOSE=1 stack from m-c rev 45709b7b6466

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Jon, not sure if bug 1233109 is the regressor here, is it?

Comment 4

[Jon Coppeard (:jonco)]

It looks to me like an unchecked allocation when initializing MConstant's result type set.  However I don't know how OOM is handled here.

Here's the backtrace for the failing allocation.

    0:  js_failedAllocBreakpoint at Utility.h:92
    1:  js::oom::ShouldFailWithOOM at Utility.h:138
    2:  js::LifoAlloc::alloc at LifoAlloc.h:273
    3:   js::LifoAlloc::new_<js::TemporaryT::new_<js::TemporaryTypeSet, js::LifoAlloc*&, js::TypeSet::Type> at LifoAlloc.h:424
    4:  MakeUnknownTypeSet at MIR.cpp:765
    5:  js::jit::MConstant::MConstant at MIR.cpp:834
    6:  js::jit::MConstant::MConstant at MIR.cpp:789
    7:  js::jit::MConstant::New at MIR.cpp:703
    8:  js::jit::IonBuilder::initLocals at IonBuilder.cpp:1202
    9:  js::jit::IonBuilder::build at IonBuilder.cpp:825
    10:  js::jit::IonCompile at Ion.cpp:2188
    11:  js::jit::Compile at Ion.cpp:2419
    12:  js::jit::CanEnter at Ion.cpp:2512
    13:  js::RunScript at Interpreter.cpp:402
    14:  js::ExecuteKernel at Interpreter.cpp:704
    15:  js::Execute at Interpreter.cpp:736
    16:  js::ModuleObject::evaluate at ModuleObject.cpp:908
    17:  intrinsic_EvaluateModule at SelfHosting.cpp:2104

I think nbp knows more about this.

Comment 5

[Nicolas B. Pierron [:nbp]]

I will double check but I suspect Bug 1264948 fixes this issue.

It looks to me that we are using a fallible allocator in a constructor, where we should either have it in an init function, or use an infallible allocator for this.

Comment 6

[Nicolas B. Pierron [:nbp]]

This is indeed a duplicate of Bug 1264948, and the patch there remove the simulated OOM from this allocation which is supposed to be infallible.