770713 - Assertion failure: [infer failure] Missing type pushed 0: <0xf6c03040>, at jsinfer.cpp:325

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test asserts on mozilla-central revision b39f4007be5a (options -m -n -a):


gczeal(4);
var a = ['a','test string',456,9.34,new String("string object"),[],['h','i','j','k']];
var b = [1,2,3,4,5,6,7,8,9,0];
exhaustiveSliceTest("exhaustive slice test 1", a);
function mySlice(a, from, to) {
  var returnArray = [];
  try {  }  catch ( [ x   ]   ) {  }   finally {  }
  return returnArray;
}
function exhaustiveSliceTest(testname, a) {
  var x = 0;
    for (y = (2 + a.length); y >= -(2 + a.length); y--) {
      var c = mySlice(a,x,y);
      if (String(b) != String(c))
          " expected result: " + String(c) + "\n";
    }
}


S-s because infer failures can be security-critical.

Comment 1

[Jesse Ruderman]

The first "bad" revision is:
changeset:   f2a937c4fb99
user:        Jon Coppeard <[e-mail]>
date:        Fri Jun 22 11:25:21 2012 +0100
summary:     Bug 763984: Add new zeal modes to test incremental GC r=billm

Comment 2

[Daniel Veditz [:dveditz]]

taking off "js-triage-needed" in case that's interfering with the new js triage process

Comment 3

[Jon Coppeard (:jonco)]

(In reply to Jesse Ruderman from comment #1)

I can reproduce this (using the script below) back to:

changeset:   8d857c53bc0a
user:        Bill McCloskey <[e-mail]>
date:        Tue Jun 12 12:24:31 2012 -0700
summary:     Bug 753283 - Poison VM stack to help fuzzers (r=bhackett)

I guess this means that this is an existing problem that has been highlighted by this change.

gczeal(4);
var a = ['a','test string',456,9.34,new String("string object"),[],['h','i','j','k']];
var b = [1,2,3,4,5,6,7,8,9,0];
function mySlice(a, from, to) {
  var returnArray = [];
  try {  }  catch ( [ x   ]   ) {  }   finally {  }
  return returnArray;
}
function exhaustiveSliceTest(testname, a) {
  var x = 0;
    for (y = (2 + a.length); y >= -(2 + a.length); y--) {
      var c = mySlice(a,x,y);
      if (String(b) != String(c))
          " expected result: " + String(c) + "\n";
    }
}
exhaustiveSliceTest("exhaustive slice test 1", a);
exhaustiveSliceTest("exhaustive slice test 1", a);
exhaustiveSliceTest("exhaustive slice test 1", a);
exhaustiveSliceTest("exhaustive slice test 1", a);

Comment 4

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: patch

Here's what's happening. At the end of a RETSUB bytecode, we call the write barrier verifier (as we do at the end of every bytecode). However, RETSUB has a funny way of incrementing the PC. It causes the stack scanning part of the barrier verifier to think that we're at the start of the function, which leads to incorrect information about what vars are live, and we end up overwriting a live variable as if it were dead.

The fix is to use a slightly less weird way of updating the PC in JSOP_RETSUB. I didn't see any other ops that work this way.

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This only affects the verifier.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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

Comment 7

[Ryan VanderMeulen [:RyanVM]]

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

Comment 8

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

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