I think this is working as intended; the effect of the script you have is to try and allocate 600MB of memory inside a single tab.  Given that circumstance, I'm inclined to think the right response is for the tab to crash.  What did you want to happen?  

pavel.zaruba@Could you please respond to comment #1?

Well, my opinion is different. Chromium is used by other 'runtimes', e.g. electron. Let's say an electron app needs to download an update file. When the app is downloading the update, it suddenly crashes. Developers can't inform user since whole process crashed and app window got black. Better would be for example to call abort or error event and inform the app about the error.

	xhr.onabort = function(e) {
	}

	xhr.onerror = function(e) {
	}	


Developers could do something with it in that case. A message could be passed to event handler, sth like 'Insufficient memory' or 'Not enough memory allocated' in case it is memory issue. I've attached screenshot of task manager performance tab before and after the crash.


What comes to "I think this is working as intended", I suppose that the crash is invoked intentionally, something like this:

int *array = malloc(buff_size * sizeof(unsigned char));
if (array == NULL) {
  force_crash();
}

or it is caused unintentionally by "dereferencing null pointer" etc. So I can't think it is working as it should.

Btw is it really problem to allocate 600 MB for Chromium with 1 tab running alone on clear Windows 7 32 bit installation?

Deleted: crash.png 84.7 KB

	crash.png 84.7 KB View Download

Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

My belief is that we've made the policy decision in Chrome to not allow arbitrary web pages to take up arbitrary amounts of computer memory to avoid DOS attacks, though I grant responding by crashing isn't necessarily the best UI.  Seth: Are you an appropriate person to speak to this?

Chromium is used in Electron (http://electron.atom.io/) as well. So it can be a single page application. The whole app crashes in that case and developer can't do anything about it.

When app creates request and something is wrong with the connection, or with the server, client gets appropriate error (error/abort event handler is called), but if the client loads more and more data, the whole app crashes. That's bad. Why not to simply close the request with error report in the same way as there would be a problem with connection/fetching data on the server? A request can't be fulfilled, so error is thrown. Why crash of whole application? (in Chrome browser sense, just a web page). 

We generally don't have OOM handling in the renderer process. But, according to the fetch spec (https://fetch.spec.whatwg.org/) and the XHR spec (https://xhr.spec.whatwg.org/), we should throw a JavaScript exception when we fail to allocate an ArrayBuffer.

Catching exception in an asynchronous code is quite problematic.
See this: https://www.joyent.com/developers/node/design/errors

You couldn't do sth. like this to handle OOM:

try {
    xhr = new XMLHttpRequest();
    xhr.open('GET', url);
    xhr.responseType = 'arraybuffer';
    xhr.send();
    xhr.onprogress = function(e) {};
    xhr.onload = function(e) {};
    xhr.onerror = function(e) {};
    xhr.onabort = function(e) {};
} catch (e) {
    console.log(e);
}

Regarding XHR, terminating fetching and calling onerror when we can't allocate an ArrayBuffer seems the right behavior. 

Yes, it seems to be the right way. Definitely better than a crash.

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

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

Closing as Fixed - at least part of the problem is fixed.

ArrayBuffer allocation failure is handled by sof@'s change [1].

1: https://chromium.googlesource.com/chromium/src/+/7c838d986a3d95e81971ef40050fecce0ea2be2c