Closed Bug 865626 Opened 7 years ago Closed 7 years ago

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

Categories

(Core :: JavaScript Engine, defect, critical)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla23
Tracking Status
firefox21 --- unaffected
firefox22 --- unaffected
firefox23 --- verified
firefox-esr17 --- unaffected
b2g18 --- unaffected

People

(Reporter: decoder, Assigned: bhackett)

References

(Blocks 1 open bug)

Details

(5 keywords, Whiteboard: [jsbugmon:update,ignore][adv-main23-])

Crash Data

Attachments

(1 file)

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();
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.
Blocks: IonFuzz
Crash Signature: [@ getInterval]
Keywords: crash
Whiteboard: [jsbugmon:update,bisect]
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
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.
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.
Flags: needinfo?(bhackett1024)
@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 ...
Attached patch patchSplinter Review
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.
Assignee: general → bhackett1024
Attachment #741859 - Flags: review?(dvander)
Flags: needinfo?(bhackett1024)
I'm assuming the regression found is accurate, and that missing a type barrier could lead to some badness.  Adjust as necessary.
Attachment #741859 - Flags: review?(dvander) → review+
Duplicate of this bug: 865632
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 0e45f1b9521f).
https://hg.mozilla.org/mozilla-central/rev/aa1e31f9cfa4
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
Marking status-firefox23:verified based on comment 11.
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:update,ignore][adv-main23-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.