1385842 - Assertion failure: !hasFlags(1 << InWorklist), at js/src/jit/MIR.h:734 with OOM

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[Christian Holler (:decoder)]

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

loadFile(`
function testBitOrAnyInconvertibleObject() {
  var count = 0;
  function nbuf() { ++count; }
  var o = ([].get);
  try {
        var q = 1 | o;
  } catch (e) {}
}
testBitOrAnyInconvertibleObject()
`);
function loadFile(lfVarx) {
  try {
    oomTest(function() {
      eval(lfVarx);
    });
  } catch (lfVare) {}
}



Backtrace:

 received signal SIGSEGV, Segmentation fault.
0x00000000007b1ad1 in js::jit::MDefinition::setInWorklist (this=0x7ffff39b5e38) at js/src/jit/MIR.h:734
#0  0x00000000007b1ad1 in js::jit::MDefinition::setInWorklist (this=0x7ffff39b5e38) at js/src/jit/MIR.h:734
#1  js::jit::LRecoverInfo::appendDefinition (def=0x7ffff39b5e38, this=0x7ffff39b8980) at js/src/jit/LIR.cpp:235
#2  js::jit::LRecoverInfo::appendResumePoint (this=this@entry=0x7ffff39b8980, rp=rp@entry=0x7ffff39b4e30) at js/src/jit/LIR.cpp:247
#3  0x00000000007b1b7c in js::jit::LRecoverInfo::init (this=0x7ffff39b8980, rp=0x7ffff39b4e30) at js/src/jit/LIR.cpp:267
#4  0x00000000007b1d7e in js::jit::LRecoverInfo::New (gen=<optimized out>, mir=0x7ffff39b4e30) at js/src/jit/LIR.cpp:203
#5  0x00000000008c29c9 in js::jit::LIRGeneratorShared::getRecoverInfo (this=0x7fffffff8100, rp=<optimized out>) at js/src/jit/shared/Lowering-shared.cpp:155
#6  0x00000000008c48ae in js::jit::LIRGeneratorShared::buildSnapshot (this=this@entry=0x7fffffff8100, ins=ins@entry=0x7ffff39b87d8, rp=<optimized out>, kind=kind@entry=js::jit::Bailout_DuringVMCall) at js/src/jit/shared/Lowering-shared.cpp:244
#7  0x00000000008c4e5c in js::jit::LIRGeneratorShared::assignSafepoint (this=0x7fffffff8100, ins=0x7ffff39b87d8, mir=0x7ffff39b6308, kind=js::jit::Bailout_DuringVMCall) at js/src/jit/shared/Lowering-shared.cpp:310
#8  0x000000000077d039 in js::jit::LIRGenerator::visitInstruction (this=this@entry=0x7fffffff8100, ins=ins@entry=0x7ffff39b6308) at js/src/jit/Lowering.cpp:5032
#9  0x000000000079586f in js::jit::LIRGenerator::visitInstruction (ins=0x7ffff39b6308, this=0x7fffffff8100) at /srv/jenkins/jobs/mozilla-central-build-jsshell/workspace/arch/64/compiler/gcc/sanitizer/none/type/debug/dist/include/mozilla/GuardObjects.h:119
#10 js::jit::LIRGenerator::visitBlock (this=this@entry=0x7fffffff8100, block=block@entry=0x7ffff39b4c90) at js/src/jit/Lowering.cpp:5114
#11 0x0000000000795c1b in js::jit::LIRGenerator::generate (this=this@entry=0x7fffffff8100) at js/src/jit/Lowering.cpp:5182
#12 0x00000000006ecf1b in js::jit::GenerateLIR (mir=mir@entry=0x7ffff39b31c0) at js/src/jit/Ion.cpp:1874
#13 0x00000000007149a1 in js::jit::CompileBackEnd (mir=mir@entry=0x7ffff39b31c0) at js/src/jit/Ion.cpp:1969
#14 0x0000000000434b4b in js::jit::IonCompile (cx=cx@entry=0x7ffff6924000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x0, osrPc=osrPc@entry=0x0, recompile=<optimized out>, optimizationLevel=<optimized out>) at js/src/jit/Ion.cpp:2254
#15 0x0000000000714efb in js::jit::Compile (cx=cx@entry=0x7ffff6924000, script=script@entry=..., osrFrame=osrFrame@entry=0x0, osrPc=osrPc@entry=0x0, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2447
#16 0x0000000000715098 in js::jit::CanEnter (cx=cx@entry=0x7ffff6924000, state=...) at js/src/jit/Ion.cpp:2544
#17 0x000000000053d4a2 in js::RunScript (cx=0x7ffff6924000, state=...) at js/src/vm/Interpreter.cpp:385
#18 0x000000000053d8c6 in js::InternalCallOrConstruct (cx=cx@entry=0x7ffff6924000, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:487
#19 0x000000000053db78 in InternalCall (cx=cx@entry=0x7ffff6924000, args=...) at js/src/vm/Interpreter.cpp:514
#20 0x000000000053dc7a in js::CallFromStack (cx=cx@entry=0x7ffff6924000, args=...) at js/src/vm/Interpreter.cpp:520
#21 0x000000000061a767 in js::jit::DoCallFallback (cx=0x7ffff6924000, frame=0x7fffffff9b98, stub_=<optimized out>, argc=<optimized out>, vp=0x7fffffff9b58, res=...) at js/src/jit/BaselineIC.cpp:2589
#22 0x00003aa2b005f8eb in ?? ()
[...]
#32 0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffff39b8980	140737280444800
rcx	0x7ffff6c28a2d	140737333332525
rdx	0x0	0
rsi	0x7ffff6ef7770	140737336276848
rdi	0x7ffff6ef6540	140737336272192
rbp	0x7fffffff7e40	140737488322112
rsp	0x7fffffff7df0	140737488322032
r8	0x7ffff6ef7770	140737336276848
r9	0x7ffff7fe4740	140737354024768
r10	0x58	88
r11	0x7ffff6b9f750	140737332770640
r12	0x7ffff39b3020	140737280421920
r13	0x7ffff39b8980	140737280444800
r14	0x7ffff39b5f40	140737280433984
r15	0x7ffff39b5e38	140737280433720
rip	0x7b1ad1 <js::jit::LRecoverInfo::appendResumePoint(js::jit::MResumePoint*)+321>
=> 0x7b1ad1 <js::jit::LRecoverInfo::appendResumePoint(js::jit::MResumePoint*)+321>:	movl   $0x0,0x0
   0x7b1adc <js::jit::LRecoverInfo::appendResumePoint(js::jit::MResumePoint*)+332>:	ud2

Comment 1

[Fuzzing Team]

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

The "good" changeset has the timestamp "20151013053056" and the hash "8d9c20c241be7d7b3cfa90a3368a77db42172781".
The "bad" changeset has the timestamp "20151013054956" and the hash "d80f9d6921f8209ef01aa730be9a97ab727704d1".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8d9c20c241be7d7b3cfa90a3368a77db42172781&tochange=d80f9d6921f8209ef01aa730be9a97ab727704d1

Comment 2

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

Attachment: OOM_VERBOSE=1 stack at 2521 allocation

Comment 3

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

Attachment: OOM_VERBOSE=1 stack at 2520 allocation

Comment 4

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

Jon, which one of the OOM_VERBOSE=1 stacks (2521 or 2520) would have been useful for you?

Comment 5

[Jon Coppeard (:jonco)]

This looks like a JIT issue.

Comment 6

[Nicolas B. Pierron [:nbp]]

The problem we see here is that buildSnapshot is called from assignSnapshot and from assignSafepoint in case of OOM under buildSnapshot.  As we fail to build the vector which contains the recover info, we do not go through the loop used to clean the Worklist flags added on MDefinition during the recursive descent of LRecoverInfo::appendDefinition.

As our Lowering got converted to be infallible, we are now continuing the execution, only reporting issues at the end of the visitInstruction call.  Thus assignSafepoint get called even if assignSnapshot failed earlier.  As we did not produced any LRecoverInfo for the given resume point, we attempt to create another one under assignSafepoint.  Thus reach the dirty InWorklist flag remaining from the last attempt.

Moving the clean-up code in a ScopeExit function should help removing this error without adding any code to be executed in normal path of execution.

Note, without OOM, LRecoverInfo is only built once as the result is cached for the last query made by assignSnapshot.

Comment 7

[Nicolas B. Pierron [:nbp]]

Attachment: Clean-up InWorklist flags in case of OOM.

Use MakeScopeExit to always remove the InWorklist flags, even in case of
failures.

See comment 6 for why this is needed.

Comment 8

[Ted Campbell [:tcampbell]]

Comment on attachment 8909892 [details] [diff] [review]
Clean-up InWorklist flags in case of OOM.

Review of attachment 8909892 [details] [diff] [review]:
-----------------------------------------------------------------

Nice fix.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/15f2fbd686f6
Clean-up InWorklist flags in case of OOM. r=tcampbell

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/15f2fbd686f6

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Can we land a test for this?

Comment 12

[Nicolas B. Pierron [:nbp]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #11)
> Can we land a test for this?

The test case reported in comment 0 takes ~10s, so I preferred to not add it.