TM: "Assertion failure: hasInt32Repr(*vp),"

RESOLVED DUPLICATE of bug 609502

Status

()

defect
--
critical
RESOLVED DUPLICATE of bug 609502
9 years ago
9 years ago

People

(Reporter: gkw, Assigned: paul.biggar)

Tracking

(Blocks 1 bug, {assertion, regression, testcase})

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

{
    function a() {}
}
Math.floor(Math.d)
function c() {}
c()
for each(let b in [0, 0, 0, 0, 0, 0, 0, -2147483648]) {
    print(Math.abs(b))
}

asserts js debug shell on TM changeset d31f58102b38 with -j at Assertion failure: hasInt32Repr(*vp)
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   57110:96a84cd98d84
user:        David Mandelin
date:        Thu Nov 11 16:51:30 2010 -0800
summary:     Bug 584603: don't optimize names to JSOP_GETGLOBAL if the function contains JSOP_DEFFUN, r=dvander
Blocks: 584603
blocking2.0: --- → ?
This has something to do with the fact that -2147483648 is a 32-bit integer but its absolute value 2147483648 is not -- if you change the test to use -2147483647 or -2147483649 the assertion doesn't fail.

The relevant code in determineSlotType() looks like this:

    if (vp->isNumber()) {
        LIns *i = getFromTracker(vp);
        JSValueType t;
        if (i) {
            t = IsPromoteInt(i) ? JSVAL_TYPE_INT32 : JSVAL_TYPE_DOUBLE;
        } else if (isGlobal(vp)) {
            ...
        }
        JS_ASSERT(t != JSVAL_TYPE_UNINITIALIZED);
        JS_ASSERT_IF(t == JSVAL_TYPE_INT32, hasInt32Repr(*vp));
        return t;
    }

'vp' is a double with the value 2147483648.  'i' and its ancestors look like this:

      payload = ldi.iterprops cursor[0]
      ...
      INT_MIN = immi 0x80000000
      isIntMin = eqi payload, INT_MIN/*0x80000000*/
      xt1: xt isIntMin -> exit=0x85517ac pc=0x854a9f6 imacpc=(nil) sp+56 rp+0 MI
SMATCH
      negi1 = negi payload
      isNeg = lti payload, strict/*0*/
      i = cmovi isNeg ? negi1 : payload

So IsPromoteInt(i) is true.
Looks to be the same problem, introduced by the same commit. Looks like changeset:   57110:96a84cd98d84 unveiled a latent bug.
Assignee: general → pbiggar
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 609502
blocking2.0: ? → betaN+
Sayre: another dup marked as a blocker.  Again, I've removed the flag.
blocking2.0: betaN+ → ---
blocking2.0: --- → betaN+
You need to log in before you can comment on or make changes to this bug.