678782 - TI: Assertion failure: vp->isString() || vp->isUndefined() || vp->isBoolean(), at jstypedarray.cpp:820

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on TI revision 1876d7b33e2f (run with -j -m -n -a), tested on 64 bit:


var i = -1; var j = -1; var s = ''; var f = '';
var buf = serialize(new Date(NaN));
var a = [1/0, -1/0, 8.64e15 + 1, -(8.64e15 + 1)];
for (var i = 0; i < a.length; i++) {
    var n = a[i];
    var nbuf = serialize(n);
    for (var Number ; j < 8; j++)
        buf[j + 8] = nbuf[j];
}

Comment 1

[Brian Hackett [Laid off!]]

Attachment: patch

Bug in typed array accesses wrt their interaction with type barriers.  A Uint8Array access had only ever had out of bounds reads when compiled, but did not have type barriers because the array had not been read from by the VM and had int added as a possible element type.

The basic problem here I think is that the semantics of how property accesses with getter hooks interact with type barriers were ill defined.  This patch clarifies things, and tightens property type information to cover only what we are actually compiling.  Property types will only be accurate for native properties and dense array elements, and when compiling other property accesses the compiler writer needs to take advantage of specialized knowledge about the property (like lengths for arrays, and element types for typed arrays) rather than look at type barriers on the opcode.

Jan, do you mind looking over the typed array access changes here?

http://hg.mozilla.org/projects/jaegermonkey/rev/a4599ee114dc

Comment 2

[Jan de Mooij [:jandem]]

Comment on attachment 553970 [details] [diff] [review]
patch

Review of attachment 553970 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/methodjit/FastOps.cpp
@@ +1858,5 @@
> +    // that have been read out of it to figure out how to do the load.
> +
> +    //                          Array contents
> +    //                   Float     Uint32         Int32
> +    // Observed types

Nice comment.

@@ +1984,3 @@
>      stubcc.rejoin(Changes(2));
>  
>      finishBarrier(barrier, REJOIN_FALLTHROUGH, 0);

Can we remove this line and the "BarrierState barrier" declaration now?

Comment 3

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/bug678782.js.