# Bad chromium bug - initialization of typed arrays



## jssd (Oct 2, 2021)

In www/chromium 92.0.4515.159 I have run into a really bad bug - typed array initialization results in garbage instead of zeros.  This has been filed as bug 258762 but I have not yet seen any activity in bugzilla, so I thought I'd bring it up here.

The basic problem is, if you can trigger the bug, the following happens:

```
var r = new Int32Array(38);
r
Int32Array(38) [-399179776, -1610579712, 399179775, 1610579711, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
```

That is, some elements of the array are not zero.  To trigger the bug, load the following as an HTML file in chromium, open devtools, and go to the console.

```
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Array Initialization BUG</title>
</head>
<body>

<script>
var arrays = [];

function doOneArray() {
    var q = new Int32Array(1000000);
    arrays.push(q);
}

for (var i=0; i<2000; i++) {
    doOneArray();
    if (arrays.length % 100 === 0) {
        console.log('PROGRESS',arrays.length);
    }
}

console.log('NOW TYPE THE FOLLOWING TWO COMMANDS INTO THE CONSOLE, MANUALLY:');
console.log(' var r = new Int32Array(38);');
console.log(' r');
console.log('Refresh the page and repeat. After a few cycles, you will find that r is full of garbage - not initialized to zeros. Takes up to 10 refreshes.');

</script>


</body>
</html>
```

The basic idea of the repro is to allocate lots of typed arrays over and over again.  At some point, after refreshing the page a few times, the manual allocation run in the console after the page loads shows the bug.

This is the simplest repro I could come up with.  In practice, my company's complex javascript application completely fails to run in www/chromium because of this bug.  It relies heavily on many typed arrays, using lots of memory, and quickly runs into the garbage initialization problem, even without the page refreshes.  This bug does not happen in Google Chrome on Windows or MacOS.  I do not know if it happens in Linux chromium.

Does anyone else see this?  Any suggestions on how to get the attention of the port maintainer(s)?  This seems like a memory leak to me, one that could have security implications, creating a situation more serious than just garbage typed arrays.


----------



## shkhln (Oct 2, 2021)

Terminology nitpick: this isn't a memory leak by any definition of memory leaks.

Anyway, would you mind rewriting that html file so it doesn't require typing things into developer console? You only need something like 
	
	



```
if (new Int32Array(38).every(n => n == 0)) document.write('pass') else document.write('fail');
```
 That should make this repro considerably less annoying.


----------



## jssd (Oct 2, 2021)

I said it _seems _like a memory leak.  I don't understand why that's a bad guess, but I'll leave it to the chromium experts.  

I did attempt something like you suggest to make the repro easier, and wasn't successful in the time I had.  A simple repro may require interaction with devtools.  Given that I've rolled my system back so I can keep doing my day job, I'll need to find some time to try again.  Will try to get a more acceptable repro that does not require devtools early next week.  Thanks for your interest in the problem.


----------



## shkhln (Oct 2, 2021)

jssd said:


> I did attempt something like you suggest to make the repro easier, and wasn't successful in the time I had.  A simple repro may require interaction with devtools.  Given that I've rolled my system back so I can keep doing my day job, I'll need to find some time to try again.  Will try to get a more acceptable repro that does not require devtools early next week.


Eh, already done


----------



## jssd (Oct 4, 2021)

Wow - thanks!!! Were you able to reproduce the problem with it? I just upgraded to Chromium 92 (again) and confirmed for myself that your repro catches the problem. Thanks again and sorry I didn't come up with this myself. Bugzilla was updated a few hours ago - looks like someone on that team has also reproduced the problem. Now to roll back again so I can keep doing my day job


----------

