Using max stack limit to determine current js engine and revision

Andrea Giammarchi andrea.giammarchi at
Wed Mar 21 01:59:11 PDT 2012

not sure if it's setTimeout problem but this snippet

(function (Function, MAX_EXECUTION_STACK) {
  if (MAX_EXECUTION_STACK in Function) return;
  Function[MAX_EXECUTION_STACK] = function (i) {
    try {
      (function max(){
        ++i && max();
    } catch(o_O) {
      return i;
}(Function, "MAX_EXECUTION_STACK"));
// browser dependentalert(Function.MAX_EXECUTION_STACK);

from here:

never gave me problems.


On Tue, Mar 20, 2012 at 9:28 PM, Mark S. Miller <erights at> wrote:

> On Tue, Mar 20, 2012 at 12:51 PM, David Bruant <bruant.d at> wrote:
>> Mark Miller:
>> > As an ES5 library without code verification or rewriting, there's
>> > nothing that SES can reasonably do about this. Perhaps this is
>> > something to address eventually once SES is made into a de jure
>> standard.
>> I see 2 cases:
>> 1) The untrusted code is being run in a sandbox. This sandbox can decide
>> to do some rewriting before running the code and I'm confident the stack
>> size and even message queue size can be controlled by the sandbox.
> Why are you confident? What do you mean by "controlled"? Limiting the
> total amount of memory is not the issue.
> The issue I worry about, as indicated by my previous links to <
>> and <
>>, is an
> attacker causing a defender to lose integrity by causing the defender to
> abort forward execution at an unexpected and vulnerable point, but for
> execution to then proceed among the defender's objects after this
> occurrence.
> To stress the problem, I like to pose the following puzzle to Java
> programmers:
> You are given a properly formed conventional doubly linked list. Write a
> function which, when called, will attempt to splice in an element.
> a) If no exceptional conditions occur, the function must return in a state
> where the splice succeeded.
> b) Under all exceptional conditions allowed by the Java and JVM contracts,
> if the function exits (whether by return or throwing), it must exit in a
> state in which the doubly linked list is still well formed. The splice may
> or may not have occurred.
> You may assume only one thread is executing.
> The reason that all conventional answers to this challenge fail is that a
> JVM VirtualMachineError (including an OutOfMemoryError) can be thrown
> between any pair of instructions. In order to succeed at goal #a, at some
> point one of the doubly linked list's pointers need to be updated, leaving
> the list ill formed. After that, a VirtualMachineError may be thrown. We
> might put the whole thing into a try/catch or try/finally to try to restore
> the list to its original state in this circumstance, but another
> VirtualMachineError may prevent any progress there as well. The only
> solution is for the function *not* to exit once the shared data structure
> it is to update might be in an ill-formed state.
> Getting back to SES, SES as a library on ES5 without translation or
> verification cannot solve this puzzle. With translation, verification, or
> direct implementation, it can do what Joe-E and Erlang do: abort the
> process, abandoning all possibly corrupt state. In the browser context, we
> could perhaps force a reload.
>> 2) The untrusted code runs un-sandboxed like if it was trusted code
>> (thanks to an XSS or whatever reason). In that case, it often means that
>> you're in bigger trouble than the untrusted code being able to figure
>> out the specific version of your platform.
> I'm not worried about untrusted code being able to figure out what
> platform it's on. I do not think it useful to try to address that threat
> model, including for the reasons you state.
>> So I don't see a use for the language to address this particular issue.
> depends what issue you're worried about ;).
>> David
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> --
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list