766075 - Assertion failure: (ptrBits & 0x7) == 0, at ../../jsval.h:700

Status: RESOLVED DUPLICATE of bug 777643

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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


try {
    eval("tostr=Boolean.prototype.toString; x=new String( 'hello' ); x.toString=tostr; x.toString()") 
} catch(exc1) {}
evaluate("mjitChunkLimit(5)");
var appendToActual = function(s) {
    actual += s + ',';
}
actual = '';
function f(t) {
  for (var i = 0; i < 10; ++i) {
    var a = arguments;
    (x.length);
    appendToActual(a.length);
  }
}
f(false, 1, 2, 3);


S-s due to assertion known to be dangerous (and this crashed in a less reduced version in opt-builds).

Comment 1

[Jesse Ruderman]

The first "bad" revision is:

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

Comment 2

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

This looks like a chunked compilation bug, similar to bug 762653. However, this test case seems to involve inlining, so they might not be the same.

Comment 3

[Christian Holler (:decoder)]

I got two more test cases here with the same assert and involving mjitChunkLimit():

function compareSource(expect, actual, summary) {}
evaluate("mjitChunkLimit(5)");
var UBOUND=100;
for (var j=0; j<UBOUND; j++)
  'Apfelkiste, Apfelschale'.replace('Apfel', function() {
      for (var i = 0; (compareSource) < arguments.length; i++)
        printStatus(i+': '+arguments[i]);
   });

=========

mjitChunkLimit(10);
var arr = [0, 1, 2, 3, 4];
function replacer() {
  assertEq(arguments.length, 2);
  var key = arguments[0], value = arguments[1];
  return value;
}
assertEq(JSON.stringify(arr, replacer), '[0,1,2,3,4]');



It would be good to verify that this is actually the same bug, or open new bugs for these if they turn out to be different issues.

Comment 4

[Christian Holler (:decoder)]

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

Comment 5

[Christian Holler (:decoder)]

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

The first good revision is:
changeset:   100659:01a7a9d46117
user:        Luke Wagner
date:        Thu Jul 26 16:08:26 2012 -0700
summary:     Bug 777643 - re-enable arguments.length fast path in JM (r=bhackett)

Comment 6

[Christian Holler (:decoder)]

I assume the change in comment 5 did not actually fix the problem, did it? Bill, can you confirm this?

Comment 7

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

(In reply to Christian Holler (:decoder) from comment #6)
> I assume the change in comment 5 did not actually fix the problem, did it?
> Bill, can you confirm this?

Yeah, it seems pretty unlikely that that fixed it.

Comment 8

[Christian Holler (:decoder)]

Assuming sec-critical because this assertion is usually dangerous.

Comment 9

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

Jan, I hate to do this, but since Brian is out you're most likely to understand chunk-limit bugs. Is this something you could look at? Worst case, could we not compile things with weird chunk edges?

Comment 10

[Jan de Mooij [:jandem]]

No problem. I can reproduce with the following minimized testcase (64-bit, revision in comment 0):
---
mjitChunkLimit(10);
function f() {
    assertEq(arguments.length, 2);
}
f("1", 10);
f("1", 10);
f("1", 10);

f is compiled in two chunks:

-------- chunk 1 --------
00000:  arguments
00001:  setlocal 0
00004:  pop
main:
00005:  callgname "assertEq"
00010:  undefined
00011:  getlocal 0

-------- chunk 2 --------
00014:  length "length"
00019:  int8 2
00021:  call 2
00024:  pop
00025:  stop

Bug 777643 fixed/replaced the broken arguments.length inline path. In most cases this path was not reachable, since top->mightBeType(JSVAL_TYPE_OBJECT) is usually false if we pushed an optimized arguments MagicValue. However, if a chunk boundary is inserted between JSOP_ARGUMENTS and JSOP_LENGTH, the FrameEntry type is unknown and we could reach this case and inline a bogus arguments.length read.

I verified this by commenting out the old arguments.length inline path and it fixes all tests in this bug. So marking this as duplicate of bug 777643.

The fix for bug 777643 will be in Firefox 17, which will be released in about two weeks.

Comment 12

[Jan de Mooij [:jandem]]

(And this is only a problem on 64-bit, on 32-bit everything works fine, since sizeof(unsigned) == sizeof(word)).