Standardizing out-of-memory and stack-depth-exceeded errors?

Joshua Bell josh at lindenlab.com
Tue Mar 22 09:07:03 PDT 2011


I was noodling with a (toy) compiler-to-JS for a (dead) language that
supports error handlers for two boundary conditions - stack depth exceeded &
out of memory - and noticed that the relevant behavior in JS is not standard
across browsers. Has there been any discussion around standardization of
errors thrown when limits of the script execution environment are hit?
(Searching the archives didn't yield hits, but my search-fu may be weak
today.)

>From briefly testing the boxes on my desk:

stack depth:
function a() { return a() + 1; } a();

* IE9: Error, message: 'Out of stack space'
* Firefox 4: InternalError, message: 'too much recursion'
* Safari 5: RangeError, message 'Maximum call stack size exceeded'
* Chrome 10: RangeError, message: 'Maximum call stack size exceeded', type:
'stack_overflow'
* Opera 11: Error, message: 'Maximum recursion depth exceeded'

memory limit:
var s = 'x'; while(true) { s = s + s; }

* IE9: Error, message: 'Out of memory'
* Firefox 4: InternalError, message 'allocation size overflow'
* Safari 5: Error, message: 'Out of memory'
* Chrome 10: sad browser tab - not catchable(?)
* Opera 11: my box ground to a crawl for several minutes; I ended up killing
the process

(That "memory" test is much weaker than the stack depth test as the browser
may simply be limiting the size strings or of one particular allocation.)

Formally describing the behavior of these runtime boundaries may be outside
the scope of ECMA-262, and some browsers choose not to expose this condition
to scripts at all and simply terminate the presumably misbehaving script
with appropriate user feedback. And in scenarios where the code is trusted
the desired behavior may be to let the process exhaust resources and let the
operating system terminate the process. But given the increase in "compile
to JavaScript" scenarios where the source language may have other exception
handling mechanisms it seems like this might be something to aim for
convergence on, at least within sandboxed environments. Any browser vendor
interest? Would discussion belong in this working group or WHATWG or ... ?

-- Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110322/f38f0727/attachment.html>


More information about the es-discuss mailing list