Thanks for reporting this! I can reproduce this in canary on mac.
Adding component Blink>JavaScript so the V8 team becomes aware of this.

Thanks for filing the issue...

Able to reproduce the issue on reported chrome version 71.0.3578.98 also on latest chrome 73.0.3649.0 using Mac 10.14.0, Ubuntu 17.10 and Windows 10.  
 
Same behavior is seen on M62(62.0.3202.0) hence considering it as non-regression and marking it as Untriaged.

Note: Observed blank page on M-60 and M-61-->Uncaught RangeError: Invalid string length

Thanks..! 

Bisected to e8c9649e2570c7e278e70a6584738a3c3f828b2b
"[builtins] Increase the maximum string length on 64-bit platforms."
Landed in 62.0.3167.0 via r489257

It was reported in  bug 791772  which got duped into another hidden issue so it's unclear what the decision was, if any.

cut-down repro:

var vArr = new Array();
var bigArray = new Array(0x20000000);
vArr[0] = String.prototype.toLowerCase.call(bigArray);
vArr[1] = String.prototype.toLowerCase.call(bigArray);
vArr[2] = String.prototype.toLowerCase.call(bigArray);

With increased string length we now run into some limit in large object space rather than just failing with a RangeError on string length. Not sure exactly what limit we are hitting here.

Lowering priority as this used to be a RangeError anyway.

Michi can you take a look? Seems that we fail to allocate a large string in LO space even after last resort GC.

The repro creates a 512M array and copies it two times successfully before failing with OOM error.

When failing with OOM the live memory is roughly 1.5G which is retained by bigArray and vArr. V8 is unable to allocate another 512M because of the default 2G heap limit.

When running with d8 the limit can be increased using `--max-old-space-size=4000` which makes the repro pass.

This all looks like working as intended. Loosening string limits does not affect our heap limits.

Why is it okay to crash the process instead of throwing an exception which can be processed by the user code?
How can the user code detect and prevent this currently?
Is there some specification that defines such a hostile approach?
Or is it a limit of the V8 architecture? If so, shouldn't it be changed?

Similar to Chrome's sandbox, the heap limits guard against malicious code as memory thrashing can take a machine hostile (freeze it). V8 in Chrome has always employed a 2G limit for JS to guard against such attacks.

Such limits are opaque to JS. OOM and similar errors are not exposed to JS. Handling would be unintuitive as one could hit an actual OOM (physical limits reached) even earlier in which case the error is always fatal.

It's not a limit of V8's architecture and as I already wrote in #8 it can be changed with --max-old-space-size at runtime if needed for non-Chrome environments (or local testing).

Previously js code could detect a RangeError exception and show a message to the user or send a beacon to the developer. So it was possible. Also what about OOM inside V8 builtins like bug 918301? It seems obviously possible and very helpful to throw an exception in such cases instead of crashing. The js code could abort its current task, do a clean up, show a meaningful message to the user, keep being functional. Lots of things. The inability to catch an OOM at least when it occurs due to a single huge internal/builtin method invocation keeps JS in the toy land.

Error handling around cases that are on the edge of being supported will always be in a grey area unless explicitly defined by some standard. 

We've improved string handling which is why there's no more RangeError in this exact scenario. Now, you've discovered that using those strings one can run into other limits. The same case (no RangeError but hard OOM) was already reproducible with a different set constants before. We just shifted what's possible a bit.

Whether JS and the web should be exposed to resource handling and recovery (memory and OOM) in this case should be answered by language and other standards committees.

Spidermonkey when processing this POC throws an exception (allocation size overflow). Why can not do the same in V8?

Without knowing what is going on there I suspect that "allocation size overflow" checks whether a specific allocation is allowed wrt to its size.

We lifted such restrictions so that this actually works in V8 and the allocations to not fail.

What we did not lift is security limits on the sandbox so that more than 2G of memory can be kept at the same time.

Throwing an error would allocate and go over said limit. So we either allow bypassing that limit or end up in an infinite loop.

That said, these are all implementation details. Whether or not JS should throw on resource errors should be discussed on the appropriate mailing lists.