Closed Bug 678782 Opened 8 years ago Closed 8 years ago

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


(Core :: JavaScript Engine, defect, critical)

Not set





(Reporter: decoder, Unassigned)


(Blocks 2 open bugs)


(Keywords: assertion, testcase)


(1 file)

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];
Attached patch patchSplinter Review
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?
Attachment #553970 - Flags: review?(jandemooij)
Closed: 8 years ago
Resolution: --- → FIXED
Comment on attachment 553970 [details] [diff] [review]

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?
Attachment #553970 - Flags: review?(jandemooij) → review+
Blocks: 676763
A testcase for this bug was automatically identified at js/src/jit-test/tests/jaeger/bug678782.js.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.