1072176 - Assertion failure: nelements <= MAX_LENGTH, at vm/SharedTypedArrayObject.cpp:519

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 1e2993c99323 (run with --fuzzing-safe --no-threads):


new SharedUint16Array(0xDEADBEEF);

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Lars T Hansen [:lth]]

Not a security issue: there is a later test that is not debug-only that catches the problem.  (The assertion is actually the bug, because the function that trips over the assertion is a public function.)

Comment 3

[Lars T Hansen [:lth]]

Memo to self: fromBuffer has the same problem as fromLength.

Comment 4

[Christian Holler (:decoder)]

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

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/ecb41e4383b3
user:        Lars T Hansen
date:        Sat Sep 20 12:12:06 2014 +0200
summary:     Bug 1068458 - Limit SharedArrayBuffer and SharedTypedArray to INT32_MAX bytes.  r=waldo

This iteration took 343.326 seconds to run.

Comment 5

[Lars T Hansen [:lth]]

(In reply to Christian Holler (:decoder) from comment #4)
> JSBugMon: Bisection requested, result:
> autoBisect shows this is probably related to the following changeset:
> 
> The first bad revision is:
> changeset:   https://hg.mozilla.org/mozilla-central/rev/ecb41e4383b3
> user:        Lars T Hansen
> date:        Sat Sep 20 12:12:06 2014 +0200
> summary:     Bug 1068458 - Limit SharedArrayBuffer and SharedTypedArray to
> INT32_MAX bytes.  r=waldo
> 
> This iteration took 343.326 seconds to run.

The error - the misplaced assertion - actually came in with an earlier patch, but bug 1068458 helped expose it.

Comment 6

[Lars T Hansen [:lth]]

Attachment: bug1072176-sab-assert.diff

A little larger than might seem warranted, but:

- Removes bogus asserts from public functions, the run-time checks are enough.
- Slightly cleans up the distinction between public and internal functions.
- Improves a couple of uninformative error messages.
- Contains test case.

Comment 7

[Jeff Walden [:Waldo]]

Comment on attachment 8494457 [details] [diff] [review]
bug1072176-sab-assert.diff

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

::: js/src/jit-test/tests/sharedbuf/toolong.js
@@ +4,5 @@
>      quit();
>  
>  var thrown = false;
>  try {
> +    new SharedUint16Array(2147483647); // Bug 1068458

So, actually.  If the max length before was INT32_MAX, technically this could work.  Bump it to Math.pow(2, 31) so as to be on the right side of the fencepost?  I guess right now we must just be OOMing, which isn't something to depend on, nor is it what this test is really supposed to test.

Comment 8

[Lars T Hansen [:lth]]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #7)
> Comment on attachment 8494457 [details] [diff] [review]
> bug1072176-sab-assert.diff
> 
> Review of attachment 8494457 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: js/src/jit-test/tests/sharedbuf/toolong.js
> @@ +4,5 @@
> >      quit();
> >  
> >  var thrown = false;
> >  try {
> > +    new SharedUint16Array(2147483647); // Bug 1068458
> 
> So, actually.  If the max length before was INT32_MAX, technically this
> could work.

No, it shouldn't, because the max *byte* length is INT32_MAX, but what's being constructed here is a SharedUint16Array.  The largest SharedUint16Array that can be constructed is actually floor(INT32_MAX/2), I guess in principle I should test that as well.

Comment 9

[Lars T Hansen [:lth]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4d131d048131

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/4d131d048131