Chrome: How to solve "Maximum call stack size exceeded" errors on Math.max.apply( Math, array ) Chrome: How to solve "Maximum call stack size exceeded" errors on Math.max.apply( Math, array ) google-chrome google-chrome

Chrome: How to solve "Maximum call stack size exceeded" errors on Math.max.apply( Math, array )


This problem has nothing to do specifically with Math.max and Math.min.

Function.prototype.apply can only receive array of limited length as its second argument.

Locally, I tested it in Chrome using:

function limit(l) {  var x = []; x.length = l;  (function (){}).apply(null, x);}

Locally, limit(l) crashed exactly with l = 124980. In canary, that was another number, but also ~125k.

This is an example explanation of why that happens: https://code.google.com/p/v8/issues/detail?id=2896 (it is also reprodusible in other JS engines, for example MDN has a mention of the issue: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/apply#Using_apply_and_built-in_functions (Starting with "But beware..."), pointing to this issue in WebKit bugzilla: https://bugs.webkit.org/show_bug.cgi?id=80797). As far as I understand why RangeError is thrown in V8:

V8 implements Function.prototype.apply in assembly. Before calling the function, it should place all function call parameters, e.g. thisArg, and all of the members of 2nd arg array, one by one, onto stack, before calling the javascript function. But the stack has limited capacity, and if you hit the limit, you will get RangeError.

This is what I've found in V8 source (IA-32 assembly, builtins-ia32.cc):

void Builtins::Generate_FunctionApply(MacroAssembler* masm) {  static const int kArgumentsOffset = 2 * kPointerSize;  static const int kReceiverOffset = 3 * kPointerSize;  static const int kFunctionOffset = 4 * kPointerSize;  {    FrameScope frame_scope(masm, StackFrame::INTERNAL);    __ push(Operand(ebp, kFunctionOffset));  // push this    __ push(Operand(ebp, kArgumentsOffset));  // push arguments    __ InvokeBuiltin(Builtins::APPLY_PREPARE, CALL_FUNCTION);    // Check the stack for overflow. We are not trying to catch    // interruptions (e.g. debug break and preemption) here, so the "real stack    // limit" is checked.    Label okay;    ExternalReference real_stack_limit =        ExternalReference::address_of_real_stack_limit(masm->isolate());    __ mov(edi, Operand::StaticVariable(real_stack_limit));    // Make ecx the space we have left. The stack might already be overflowed    // here which will cause ecx to become negative.    // !! ADDED COMMENT: IA-32 stack grows downwards, if address to its current top is 0 then it cannot be placed any more elements into. esp is the pointer to stack top.    __ mov(ecx, esp);    // !! ADDED COMMENT: edi holds the "real_stack_limit", which holds the  minimum address that stack should not grow beyond. If we subtract edi from ecx (=esp, or, in other words, "how much space is left on the stack"), we may get a negative value, and the comment above says that    __ sub(ecx, edi);    // Make edx the space we need for the array when it is unrolled onto the    // stack.    // !! ADDED COMMENT: eax holds the number of arguments for this apply call, where every member of the 2nd argument array counts as separate argument    __ mov(edx, eax);    // !! ADDED COMMENT: kPointerSizeLog2 - kSmiTagSize is the base-2-logarithm of how much space would 1 argument take. By shl we in fact get 2^(kPointerSizeLog2 - kSmiTagSize) * arguments_count, i.e. how much space do actual arguments occupy    __ shl(edx, kPointerSizeLog2 - kSmiTagSize);    // Check if the arguments will overflow the stack.    // !! ADDED COMMENT: we compare ecx which is how much data we can put onto stack with edx which now means how much data we need to put onto stack    __ cmp(ecx, edx);    __ j(greater, &okay);  // Signed comparison.    // Out of stack space.    __ push(Operand(ebp, 4 * kPointerSize));  // push this    __ push(eax);    __ InvokeBuiltin(Builtins::APPLY_OVERFLOW, CALL_FUNCTION);

Please check !! ADDED COMMENT for explanations of how I understand it.

And this is APPLY_OVERFLOW function, written in JS (again, V8 source, runtime.js):

function APPLY_OVERFLOW(length) {  throw %MakeRangeError('stack_overflow', []);}

EDIT: In your case, I would go like:

var max = -Infinity; for(var i = 0; i < arr.length; i++ ) if (arr[i] > max) max = arr[i];


To me the error shouldn't come from the call into Math.min / max it looks like the result of using recursion which I cannot beleive Chrome would use to implement those functions.

Are they embeded in recursive code?

You can roll your own min / max code trivially to avoid the problem in Chrome.


var a=[]; for(var i=0;i<1125011;i++){     a[i] = i;}function maxIterate(arr){    var max = arr[0];    for(var i = 1;i< arr.length; i++){        (max < arr[i]) && (max = arr[i])    }    return max;}console.log(maxIterate(a));

Math.max may use recursive method to get max value, just rewrite an iterating function to get max instead.This will avoid RangeError.