811572 - IonMonkey: Differential Testing: Getting different typeof result with schedulegc

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase shows different behavior with options ---ion-eager vs. no options on m-c revision 1b0226622e94:


var gTestcases = new Array();
var gTc = gTestcases.length;
function TestCase(n, d, e, a) {
  this.expect = e;
  this.actual = a;
  gTestcases[gTc++] = this;
  function getTestCaseResult(expected, actual) {
    if (typeof expected != typeof actual)
      return true;
  }
  for ( gTc=0; gTc < gTestcases.length; gTc++ ) {
      gTestcases[gTc].passed = writeTestCaseResult(
          gTestcases[gTc].expect,
          gTestcases[gTc].actual,
          gTestcases[gTc].description 
        );
  }
  function writeTestCaseResult( expect, actual, string ) {
    var passed = getTestCaseResult( expect, actual );
    print(passed);
  }
}
function InstanceOf( object, constructor )  {
  return object instanceof constructor;
}
function Employee ( name, dept ) {
  this.name = name || "";
  this.dept = dept || "general";
}
function WorkerBee ( name, dept, projs ) {
  this.base = Employee;
}
function Engineer ( name, projs, machine ) {
  schedulegc(10);
  this.base( name, "engineering", projs )
}
Engineer.prototype = new WorkerBee();
var pat = new Engineer();
new TestCase("", "InstanceOf( pat, WorkerBee )", true, InstanceOf( pat, Object ));


$ debug64/js --ion-eager test.js
true

$ debug64/js test.js
undefined


I'm marking this s-s because schedulegc is involved in the test.

Comment 1

[Christian Holler (:decoder)]

Different test, but likely the same bug, and shorter (and contains Ninjas!):


function Person( ){}
function Ninja() {}
Ninja.prototype = new Person();
var person = new Person();
var bindNinja = Ninja.bind({});
function test(v, v2) {
  return v instanceof v2;
}
schedulegc(10);
assertEq(test(new Ninja(), bindNinja), true);

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

How should we sec-rate this one?

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Probably sec-high, despite the ninjas and gc I'm suspecting something softer than a critical memory error.

Comment 4

[David Bolter [:davidb] (NeedInfo me for attention)]

Thanks. Marking sec-high.

Comment 5

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

autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   113229:6ba78023b367
user:        Brian Hackett
date:        Wed Nov 14 06:46:31 2012 -0800
summary:     Eagerly generate a single copy of Ion stubs and wrappers, bug 786146. r=dvander

Brian, did bug 786146 likely fix this?

Comment 6

[Brian Hackett [Laid off!]]

I doubt it, bug 786146 just changed how many GC things are allocated when initially compiling Ion code and will perturb schedulegc calls (testcases which use this are ultra fragile).

Comment 7

[Christian Holler (:decoder)]

This doesn't reproduce for me anymore on any branch that includes IonMonkey, so marking as WFM.