W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2015

Re: [whatwg] Handling out of memory issues with getImageData/createImageData

From: Allen Wirfs-Brock <allen@wirfs-brock.com>
Date: Sun, 27 Sep 2015 09:14:42 -0700
Message-Id: <8CA0D464-4EE6-4F21-9F78-34385D2A249E@wirfs-brock.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Justin Novosad <junov@google.com>, WHAT Working Group <whatwg@whatwg.org>, Mark Miller <erights@gmail.com>

On Sep 26, 2015, at 7:34 AM, Anne van Kesteren wrote:

> On Fri, Sep 25, 2015 at 4:48 PM, Justin Novosad <junov@google.com> wrote:
>> Currently there is no spec'ed behavior for handling out-of memory issues
>> for the specific case of attempting to allocate a large buffer through
>> image data APIs.
> Actually, there is no specified behavior for out-of-memory behavior,
> period. This is a problem that starts with the ECMAScript standard and
> everything that builds upon it.

Actually, that's not completely correct.  Within ES2015, the only way explicitly allocate a large, dense area of memory is by creating a large ArrayBuffer instance.  All attempts to create such instances eventually perform the actions specified by CreateDataBlock [1].  CreateDataBlock explicitly says that a RangeError exception is thrown if it is impossible to allocated the requested memory. 

I would expect and future ES features that exposed similar allocation capabilities to follow that same pattern.


[1]: http://ecma-international.org/ecma-262/6.0/#sec-createbytedatablock 

> I have seen Mark Miller discuss some of the issues surrounding this
> and perhaps even the necessity to eventually define it, but so far
> this has not happened. Not sure if the full story is documented
> somewhere. Mark?
> https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7
> indicates there may be security issues with throwing out-of-memory
> exceptions.
> -- 
> https://annevankesteren.nl/
Received on Sunday, 27 September 2015 16:15:12 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:35 UTC