cwallez/jmadill, do you mind following up on this please?

+cc kbr, geofflang

Running this in a Linux build I got an "Aw, snap" and the following console output that seems to indicate and OOM:

[99357:99357:0115/112905.123780:INFO:CONSOLE(89)] "WebGL: INVALID_VALUE: enableVertexAttribArray: index out of range", source: file:///usr/local/google/home/cwallez/Downloads/poc.js (89)
[99357:99357:0115/112905.124698:INFO:CONSOLE(93)] "WebGL: INVALID_VALUE: enableVertexAttribArray: index out of range", source: file:///usr/local/google/home/cwallez/Downloads/poc.js (93)
[99357:99357:0115/112905.125589:INFO:CONSOLE(97)] "WebGL: INVALID_VALUE: enableVertexAttribArray: index out of range", source: file:///usr/local/google/home/cwallez/Downloads/poc.js (97)
[99357:99357:0115/112905.126472:INFO:CONSOLE(101)] "WebGL: INVALID_VALUE: enableVertexAttribArray: index out of range", source: file:///usr/local/google/home/cwallez/Downloads/poc.js (101)
[99357:99357:0115/112905.127367:INFO:CONSOLE(105)] "WebGL: INVALID_VALUE: enableVertexAttribArray: index out of range", source: file:///usr/local/google/home/cwallez/Downloads/poc.js (105)
[99357:99357:0115/112905.128251:INFO:CONSOLE(109)] "WebGL: INVALID_VALUE: enableVertexAttribArray: index out of range", source: file:///usr/local/google/home/cwallez/Downloads/poc.js (109)

<--- Last few GCs --->

[1:0xda7a29cc020]      350 ms: Scavenge 4.5 (7.2) -> 4.1 (7.7) MB, 1.1 / 0.0 ms  allocation failure 
[1:0xda7a29cc020]     7081 ms: Mark-sweep 1725.5 (1729.6) -> 1574.3 (1579.5) MB, 9.1 / 0.2 ms  (+ 1.6 ms in 4 steps since start of marking, biggest step 0.9 ms, walltime since start of marking 5851 ms) allocation failure GC in old space requested
[1:0xda7a29cc020]     7191 ms: Mark-sweep 1574.3 (1579.5) -> 577.8 (583.0) MB, 109.2 / 0.0 ms  allocation failure GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0xee8eae07989 <Window map = 0x13d8591829d1>
    1: initBuffers [file:///usr/local/google/home/cwallez/Downloads/poc.js:~141] [pc=0x1dfb60656068](this=0x27a5422847a9 <JSGlobal Object>)
    2: webGLStart [file:///usr/local/google/home/cwallez/Downloads/poc.js:7] [bytecode=0x20f72b7913a1 offset=45](this=0x27a5422847a9 <JSGlobal Object>)
    3: onload [file:///usr/local/google/home/cwallez/Downloads/poc.htm:54] [bytecode=0x2...

I've never seen a JS OOM before, is it considered a security bug?

Also jackwillzac, do you get similar output when running Chrome from a console locally?

On Linux I get the same output.

It's easy to provoke an out-of-memory crash in the renderer process; just allocate and retain references to lots of objects, whether they are in the JavaScript heap or on the browser's C++ side. Chrome's security architecture has been from day one to crash hard upon a failed memory allocation, to prevent NULL pointers from accidentally floating around the browser's code.

I can confirm that the part that is actually crashing is:

    for (i = 0; i < bound * 1; ++i)
    {
        colors[i] = 0xba; // represented as 0x433a0000
    }

which is in pure JavaScript code, reallocating the "colors" array over and over again as new elements are dynamically added to it.

If this were instead written as:

   var colorArray = new Float32Array(bound);
   for (i = 0; i < bound; ++i) {
        colorArray[i] = 0xba; // represented as 0x433a0000
   }

then not only would the test not crash, it would run to successful completion.

This is not a bug.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot