whatwg
Throw exception when text encode alloc memory fail.
What is the issue with the Encoding Standard?
In Edge and Chrome, we have found that TextEncoder Encoding Standard (whatwg.org) may encounter OOM (Out of Memory) errors when encode text, not only due to large memory allocation but also for some unknown reasons. Our current strategy is to crash the renderer process. We now want to optimize this behavior by throwing an exception when memory allocation fails.
I tested encode with a long string in Firefox and Safari browsers.
Firefox will throw a exception "out of memory".
Safari will return a empty UInt8Array.
I noticed that the current standards do not define how to handle OOM (Out of Memory) situations.Do we need to establish such a standard?
Crashing the website process does actually seem preferable over having to define for each API what OOM means.
There's currently no standards effort that I'm aware of around standardizing OOM, but if anything it should probably be discussed within TC39 to start with.
cc @littledan @ljharb @codehag
In practice browsers have already abandoned consistent behaviour here, as some OOM failures cause more pain for users than others. XHR is particularly terrible in Blink, as it just silently replaces the response with an empty response in case of OOM.
In this specific case, there's no danger of leaving the user agent in an inconsistent state, as we have to do the allocation before anything else. However, user JavaScript may still be in an inconsistent state. In general, the exception will stop it continuing with erroneous calculations, but if it happens to be catching and discarding exceptions when encode() is called that could be dangerous.
I recognize the wisdom of the oom-fails-fast proposal, but it doesn't reflect what engines actually do. I've had to fix security holes in Blink caused by stack overflow throwing an exception in places that the standard says should never throw.
My philosophy is that OOM should continue to crash in most cases, but we need to pragmatically carve out exceptions in cases that cause particular user pain. As such, I'd like to attempt convergence between browsers on those exceptions, and one way to do that is to specifically mention them in the relevant standards.
Chromium does seem to throw the wrong exception here. It's the allocation of ArrayBuffer that fails and that should lead to a RangeError exception, per JS.
Based on https://commits.webkit.org/293416@main WebKit appears to throw a TypeError in the string case. Need to investigate if that's the way to go.
As per https://github.com/tc39/ecma262/issues/2623 we should use a RangeError for the string case as well. That will require a change.