866706 - IonMonkey: Assertion failure: mir->type() == MIRType_Value, at ion/x64/Lowering-x64.cpp:19

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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


var MyMath = {
  random: function() {
    this.seed = (this.seed + 0x7ed55d16) & 0xffffffff;
    return (this.seed & 0xfffffff) / 0x10000000;
  }
};
var kSplayTreeSize = 8000;
function GenerateKey() {
  return MyMath.random();
}
function InsertNewNode() {
  do {
    key = GenerateKey();
  } while (splayTree.find(key) != null);
  splayTree.insert(key);
}
splayTree = new SplayTree();
for (var i = 0; i < kSplayTreeSize; i++)
  InsertNewNode();
function SplayTree() {
  SplayTree.prototype.isEmpty = function() {
    return !this.root_;
  };
  SplayTree.prototype.insert = function(key, value) {
    this.root_ = new SplayTree.Node(key, value);
  };
  SplayTree.prototype.find = function(key) {
    if (this.isEmpty()) {
      return null;
    }
    var right = new SplayTree.Node(null, null);
    var current = this.root_;
    while (true) {
      if (key < current.key) {
        right.left = current;
      } else if (key > current.key) {
          break;
      }
      current ^= tmp;
      break;
    }
  };
  SplayTree.Node = function(key, value) {
    this.key = key;
  };
}

Comment 1

[Christian Holler (:decoder)]

Backtrace of the assertion:

Program received signal SIGSEGV, Segmentation fault.
bt
0x0000000000958f01 in js::ion::LIRGeneratorX64::useBox (this=0x7fffffffcd60, lir=0xf5b750, n=0, mir=0xf521c0, policy=<optimized out>, useAtStart=<optimized out>)
    at js/src/ion/x64/Lowering-x64.cpp:19
19          JS_ASSERT(mir->type() == MIRType_Value);
(gdb) bt
#0  0x0000000000958f01 in js::ion::LIRGeneratorX64::useBox (this=0x7fffffffcd60, lir=0xf5b750, n=0, mir=0xf521c0, policy=<optimized out>, useAtStart=<optimized out>)
    at js/src/ion/x64/Lowering-x64.cpp:19
#1  0x00000000008cd15a in js::ion::LIRGenerator::visitMonitorTypes (this=0x7fffffffcd60, ins=0xf53ad0) at js/src/ion/Lowering.cpp:1722
#2  0x00000000008c94a6 in js::ion::LIRGenerator::visitInstruction (this=0x7fffffffcd60, ins=0xf53ad0) at js/src/ion/Lowering.cpp:2659
#3  0x00000000008c9902 in js::ion::LIRGenerator::visitBlock (this=0x7fffffffcd60, block=0xf53498) at js/src/ion/Lowering.cpp:2751
#4  0x00000000008c9f2b in js::ion::LIRGenerator::generate (this=0x7fffffffcd60) at js/src/ion/Lowering.cpp:2827
#5  0x00000000008203b6 in js::ion::GenerateLIR (mir=0xf46320) at js/src/ion/Ion.cpp:1135
#6  0x00000000008222ea in CompileBackEnd (mir=0xf46320, maybeMasm=<optimized out>) at js/src/ion/Ion.cpp:1231
#7  js::ion::SequentialCompileContext::compile (this=<optimized out>, builder=0xf46320, graph=<optimized out>, autoDelete=...) at js/src/ion/Ion.cpp:1427
#8  0x0000000000822afd in js::ion::IonCompile<js::ion::SequentialCompileContext> (cx=0xe997f0, script=<optimized out>, fp=..., osrPc=0x0, constructing=<optimized out>, compileContext=...)
    at js/src/ion/Ion.cpp:1367
#9  0x0000000000822e5b in js::ion::Compile<js::ion::SequentialCompileContext> (cx=<optimized out>, script=0x7ffff6739710, fp=..., osrPc=<optimized out>, constructing=<optimized out>, compileContext=...)
    at js/src/ion/Ion.cpp:1598
#10 0x0000000000823735 in js::ion::CompileFunctionForBaseline (cx=0xe997f0, script=0x7ffff6739710, fp=..., isConstructing=false) at js/src/ion/Ion.cpp:1734
#11 0x0000000000a02707 in EnsureCanEnterIon (jitcodePtr=<synthetic pointer>, pc=<optimized out>, script=0x7ffff6739710, frame=0x7fffffffd1b8, cx=0xe997f0, stub=<optimized out>)
    at js/src/ion/BaselineIC.cpp:661
#12 DoUseCountFallback (infoPtr=0x7fffffffd180, frame=0x7fffffffd1b8, stub=<optimized out>, cx=0xe997f0) at js/src/ion/BaselineIC.cpp:844
#13 js::ion::DoUseCountFallback (cx=0xe997f0, stub=<optimized out>, frame=0x7fffffffd1b8, infoPtr=0x7fffffffd180) at js/src/ion/BaselineIC.cpp:803
#14 0x00007ffff7e17318 in ?? ()


S-s because previous similar assertions were problematic.

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:   129970:ebf1b0f1920c
user:        Brian Hackett
date:        Thu Apr 25 14:44:44 2013 -0600
summary:     Bug 865635 - Use MMonitorTypes instead of MTypeBarrier for type write barriers, r=dvander.

This iteration took 145.045 seconds to run.

Comment 3

[Brian Hackett [Laid off!]]

Attachment: patch

MMonitorTypes needs to make sure it has a boxed input.

Comment 4

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/120ca4a6afc3

Comment 5

[Andrew McCreight [:mccr8]]

I'm assuming the regression range in comment 2 is right.

Type confusion sounds bad, so I'm marking this sec-high.  Feel free to adjust as desired.

Comment 6

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/120ca4a6afc3

Comment 7

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 8

[u279076]

Marking status-firefox23:verified based on comment 7.