865626 - IonMonkey: Assertion failure: !entered && i < mLength, at js/Vector.h:364 or Crash [@ getInterval]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 690b5e0f6562 (run with --ion-eager):


var callStack = new Array();
function enterFunc (funcName) {
  if (!funcName.match(/\(\)$/))
    funcName += "()";
  callStack.push(funcName);
  return callStack[callStack.length - 1];
}
enterFunc ('test');
var c = ({}).__proto__;
var d = {};
c[0] = d;
try {
evaluate("test(); function test() enterFunc (0);");
} catch(exc1) {}
test();

Comment 1

[Christian Holler (:decoder)]

Crash trace:

Program received signal SIGSEGV, Segmentation fault.
0x083a42a7 in getInterval (i=0, this=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/LiveRangeAllocator.h:403
403             return intervals_[i];
(gdb) bt
#0  0x083a42a7 in getInterval (i=0, this=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/LiveRangeAllocator.h:403
#1  js::ion::LiveRangeAllocator<js::ion::LinearScanVirtualRegister>::buildLivenessInfo (this=0xffffc2dc) at /srv/repos/mozilla-central/js/src/ion/LiveRangeAllocator.cpp:698
#2  0x0839cf89 in js::ion::LinearScanAllocator::go (this=0xffffc2dc) at /srv/repos/mozilla-central/js/src/ion/LinearScan.cpp:1136
#3  0x0833dd2e in js::ion::GenerateLIR (mir=0x867a368) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1128
#4  0x0833f3d6 in CompileBackEnd (mir=0x867a368, maybeMasm=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1208
#5  compile (autoDelete=<synthetic pointer>, builder=0x867a368, this=<optimized out>, graph=<optimized out>) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1401
#6  IonCompile<js::ion::SequentialCompileContext> (compileContext=..., constructing=false, osrPc=0x0, fp=..., script=<optimized out>, cx=0x8661000) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1341
#7  js::ion::Compile<js::ion::SequentialCompileContext> (cx=0x8661000, script=0xf7428280, fp=..., osrPc=0x0, constructing=false, compileContext=...) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1572
#8  0x08341733 in js::ion::CanEnter (cx=0x8661000, script=0xf7428280, fp=..., isConstructing=false) at /srv/repos/mozilla-central/js/src/ion/Ion.cpp:1680
#9  0x08108594 in js::RunScript (cx=0x8661000, fp=0xf7698078) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:320
#10 0x08108ae0 in js::InvokeKernel (cx=0x8661000, args=..., construct=js::NO_CONSTRUCT) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:421
#11 0x081091fa in Invoke (construct=js::NO_CONSTRUCT, args=..., cx=0x8661000) at /srv/repos/mozilla-central/js/src/jsinterp.h:134
#12 js::Invoke (cx=0x8661000, thisv=..., fval=..., argc=0, argv=0xffffc9dc, rval=0xffffc9a4) at /srv/repos/mozilla-central/js/src/jsinterp.cpp:454
#13 0x084ce7e4 in js::ion::DoCallFallback (cx=0x8661000, frame=0xffffc9fc, stub=0x8660038, argc=0, vp=0xffffc9cc, res=$jsval(-nan(0xfff8200000000))) at /srv/repos/mozilla-central/js/src/ion/BaselineIC.cpp:6587
#14 0xf7fcd494 in ?? ()
#15 0x08660038 in ?? ()
#16 0xf7fc860e in ?? ()
#17 0x08335121 in EnterBaseline (cx=0x8660038, fp=0x0, jitcode=0xf7fd03e8, osr=false) at /srv/repos/mozilla-central/js/src/ion/BaselineJIT.cpp:154
[...]
(gdb) x /i $pc
=> 0x83a42a7 <js::ion::LiveRangeAllocator<js::ion::LinearScanVirtualRegister>::buildLivenessInfo()+2887>:       mov    (%eax),%eax
(gdb) info reg eax
eax            0x0      0


Likely a null-deref but I don't like the assertion and this crash signature was previously associated with some s-s inlining failures.

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   129593:ee14945b452c
parent:      128511:d989eab66df4
user:        Brian Hackett
date:        Thu Apr 11 18:39:32 2013 -0600
summary:     Bug 804676 - Remove dependence of Ion compilation on ScriptAnalysis::analyzeTypes.

This iteration took 141.394 seconds to run.

Oops! We didn't test rev d989eab66df4, a parent of the blamed revision! Let's do that now.
Rev d989eab66df4: Updating... Compiling... Testing... [Uninteresting] It didn't crash. (0.046 seconds)
good (not interesting) 
As expected, the parent's label is the opposite of the blamed rev's label.

Comment 3

[Christian Holler (:decoder)]

Needinfo from Brian based on comment 2. It's likely that I found this already during the review, but the crash signature looked the same as some MIRType failures we had at that time, so that's a possible reason why this slipped under the radar at that time.

Comment 4

[Hannes Verschore [:h4writer]]

@Brain: for a pointer where to look: The ones I investigated where due to inlining. So enterFunc ('test'); is called with string and everything is specialized to string. The next time enterFunc(0); is inlined. So we have a MConstant that progagates his type/value in the inlined function, but that don't correspond with the monitored resultStackType. So when not paying attention we have a MIRType = int, but view in resultStackType the monitored type is MIRType=string. I.e. when optimizing based on resultStackType we could be wrong and forget some MUnbox's or something. ComparePolicy is a frequent problem (that's the other bug, probably another MIRType that needs boxing). Here I'm not sure. Probably MBox need to get added somewhere ...

Comment 5

[Brian Hackett [Laid off!]]

Attachment: patch

When inlining Array.push the compiler needs to check if a type barrier is required when writing the value to the array.  It did this and aborted the inlining correctly, but left behind an MTypeBarrier whose input was an MPassArg.  This confused the lowering code and we crashed in the regalloc.  This patch avoids generation of this instruction.

Comment 6

[Andrew McCreight [:mccr8]]

I'm assuming the regression found is accurate, and that missing a type barrier could lead to some badness.  Adjust as necessary.

Comment 7

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/aa1e31f9cfa4

Comment 9

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 0e45f1b9521f).

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/aa1e31f9cfa4

Comment 11

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 12

[u279076]

Marking status-firefox23:verified based on comment 11.