"Maximum call stack size exceeded" with large List #1521

jinjor · Nov 30, 2016

This is the same issue as elm/elm-lang.org#671.

If we define a large static list, a runtime error "Maximum call stack size exceeded" occurs on initializing the app.

SSCCE (for Try Elm & Chrome):

import Html exposing (text)

main =
  text "Hello, World!"
  
a =
  [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
  ]

The max length might change by browsers.
A workaround is splitting it into multiple lists like ...,1,1,1] ++ [1,1,1,....

I think this happens more often than 0.17, because I first saw this error during migration to 0.18.

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

process-bot · Nov 30, 2016

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

I noticed this error recently on 0.17 as well, though only on one person's Firefox (which running the stack size test came out at something like 6000; much less than my browsers). I can't think of any large static arrays or any data processing that would lead to a recursion limit being hit so I'll have to look into it more; I'm worried it'll prove rather hard to find!

jsdw · Dec 6, 2016

I noticed this error recently on 0.17 as well, though only on one person's Firefox (which running the stack size test came out at something like 6000; much less than my browsers). I can't think of any large static arrays or any data processing that would lead to a recursion limit being hit so I'll have to look into it more; I'm worried it'll prove rather hard to find!

I think this is an issue chrome because internally creates a function call to construct a object literal. Ex:
{a:{a:{a:{}}}}
Causes a dept 4 call stack.

Elms list literals in JS are constructed with nested object literals. For lists with thousands of elements evaluating the deeply nested object literal can exceed the stack depth in chrome.

moore · Dec 9, 2016

I think this is an issue chrome because internally creates a function call to construct a object literal. Ex:
{a:{a:{a:{}}}}
Causes a dept 4 call stack.

Elms list literals in JS are constructed with nested object literals. For lists with thousands of elements evaluating the deeply nested object literal can exceed the stack depth in chrome.

It doesn't even take thousands of elements. After upgrading to 0.18, I'm getting this issue with just hundreds of items. I use a list of tuples to initialise a Dict and the code blows up with anything over 475 entries. The same thing happens if I replace the Dict.fromList call with multiple piped calls to Dict.insert. Concatenating several smaller lists seems to work though.

deepilla · Dec 11, 2016

It doesn't even take thousands of elements. After upgrading to 0.18, I'm getting this issue with just hundreds of items. I use a list of tuples to initialise a Dict and the code blows up with anything over 475 entries. The same thing happens if I replace the Dict.fromList call with multiple piped calls to Dict.insert. Concatenating several smaller lists seems to work though.

This doesn't appear to only affect lists: importing Bogdanp/elm-time's Time.TimeZoneData also crashes at runtime with a maximum call-stack error.

paulswartz · Jan 14, 2017

This doesn't appear to only affect lists: importing Bogdanp/elm-time's Time.TimeZoneData also crashes at runtime with a maximum call-stack error.

This doesn't appear to only affect lists: importing Bogdanp/elm-time's Time.TimeZoneData also crashes at runtime with a maximum call-stack error.

It crashes because of list too. There are 600 elements passed to Dict.fromList.

witoldsz · Feb 25, 2017

This doesn't appear to only affect lists: importing Bogdanp/elm-time's Time.TimeZoneData also crashes at runtime with a maximum call-stack error.

It crashes because of list too. There are 600 elements passed to Dict.fromList.

I never messed with the compiler before, but looking at the soure code and at the output
Can't we change the way it creates list ([ ,* ]) to a function that creates the js structure:
like that

function createListFromJSArray(arr){
  if(arr.length == 0){
    return { ctor: '[]' }
  }
  var prev = { ctor: '::', _0: arr[0] }
  var root = prev;
  for(var i = 1; i < arr.length; i++) {
    var curr = { ctor: '::', _0: arr[i] }
    prev._1 = curr
    prev = curr
  }
  prev._1 = { ctor: '[]' }
  return root
}

And then make the compiler generate something like
createListFromJSArray([X,Y,Z,...]) instead of outputing the data tree directly?

Edited to fix code

Edit 2:

Maybe we can just use a self calling function to avoid polluting the global namespace and maybe we should only do that for lists bigger than some length X (and maybe that can be arbitrarily long depending on how browsers change in the future)

bamorim · Mar 1, 2017

I never messed with the compiler before, but looking at the soure code and at the output
Can't we change the way it creates list ([ ,* ]) to a function that creates the js structure:
like that

function createListFromJSArray(arr){
  if(arr.length == 0){
    return { ctor: '[]' }
  }
  var prev = { ctor: '::', _0: arr[0] }
  var root = prev;
  for(var i = 1; i < arr.length; i++) {
    var curr = { ctor: '::', _0: arr[i] }
    prev._1 = curr
    prev = curr
  }
  prev._1 = { ctor: '[]' }
  return root
}

And then make the compiler generate something like
createListFromJSArray([X,Y,Z,...]) instead of outputing the data tree directly?

Edited to fix code

Edit 2:

Maybe we can just use a self calling function to avoid polluting the global namespace and maybe we should only do that for lists bigger than some length X (and maybe that can be arbitrarily long depending on how browsers change in the future)

I have this error when decoding a JSON list.

My list is 9914 item long. It decodes fine, and also renders fine once. But as soon as I touch the model (elsewhere) and re-render I got the error.

Stack trace:

app.js:14618 Uncaught RangeError: Maximum call stack size exceeded
    at Function.compare [as func] (app.js:14618)
    at A2 (app.js:13550)
    at Function.func (app.js:16987)
    at A2 (app.js:13550)
    at app.js:22680
    at app.js:13474
    at A2 (app.js:13551)
    at Function.func (app.js:17464)
    at A2 (app.js:13550)
    at Function.func (app.js:17465)

The stack trace is not very helpful, here is the full source:
https://gist.github.com/kuon/005e7ebff78a9488243e652479b60eaf

kuon · May 4, 2017

I have this error when decoding a JSON list.

My list is 9914 item long. It decodes fine, and also renders fine once. But as soon as I touch the model (elsewhere) and re-render I got the error.

Stack trace:

app.js:14618 Uncaught RangeError: Maximum call stack size exceeded
    at Function.compare [as func] (app.js:14618)
    at A2 (app.js:13550)
    at Function.func (app.js:16987)
    at A2 (app.js:13550)
    at app.js:22680
    at app.js:13474
    at A2 (app.js:13551)
    at Function.func (app.js:17464)
    at A2 (app.js:13550)
    at Function.func (app.js:17465)

The stack trace is not very helpful, here is the full source:
https://gist.github.com/kuon/005e7ebff78a9488243e652479b60eaf

@kuon I don't think this is the same issue. This issue was caused when initializing a big list in elm due to how the elm compiler created the JS code to instantiate the list. In your case this is probably being caused by something else, but it will be hard to know what without the source code. Looking at the compiled code, that may be something related to Dict. Are you creating a Dict from this list?

bamorim · May 4, 2017

@kuon I don't think this is the same issue. This issue was caused when initializing a big list in elm due to how the elm compiler created the JS code to instantiate the list. In your case this is probably being caused by something else, but it will be hard to know what without the source code. Looking at the compiled code, that may be something related to Dict. Are you creating a Dict from this list?

Ok, after tinkering and help from slack, my issue appears to be caused by the debugger.

kuon · May 4, 2017

Ok, after tinkering and help from slack, my issue appears to be caused by the debugger.

We suffer from this issue, too. The compiler will generate a large javascript file containing lots of empty lines (I think spaces).

andys8 · May 22, 2017

We suffer from this issue, too. The compiler will generate a large javascript file containing lots of empty lines (I think spaces).

@kuon

Do you have more info regarding this problem? I'm experiencing the same thing, also with large JSON lists. Did you come up with a workaround that still allows the debugger to run?

Steve-OH · Jun 6, 2017

@kuon

Do you have more info regarding this problem? I'm experiencing the same thing, also with large JSON lists. Did you come up with a workaround that still allows the debugger to run?

@Steve-OH turned the debugger off for now, I'd be interested in a better solution too

kuon · Jun 6, 2017

@Steve-OH turned the debugger off for now, I'd be interested in a better solution too

@kuon

Ah, well. I figured as much. Thanks.

Steve-OH · Jun 7, 2017

@kuon

Ah, well. I figured as much. Thanks.

I am suffering from a similar problem with about 10000 entries in a list. When the lists of my model contain less entries everything works as intended. The problem here seems to be the comparison function. This prevents me from even returning the same model in the update function.

TestView.elm:1381 Uncaught RangeError: Maximum call stack size exceeded
at Object.cmp (TestView.elm:1381)
at Function.compare [as func] (TestView.elm:1162)
at A2 (TestView.elm:92)
at Function.func (TestView.elm:3529)
at A2 (TestView.elm:92)
at TestView.elm:9222
at TestView.elm:16
at A2 (TestView.elm:93)
at Function.func (TestView.elm:4006)
at A2 (TestView.elm:92)

If there is a workaround please let me know, i tried to switch to Arrays the problem still remains (maybe because the comparison is done in the DOM part behind the scenes?).

b0urb4k1 · Sep 27, 2017

I am suffering from a similar problem with about 10000 entries in a list. When the lists of my model contain less entries everything works as intended. The problem here seems to be the comparison function. This prevents me from even returning the same model in the update function.

TestView.elm:1381 Uncaught RangeError: Maximum call stack size exceeded
at Object.cmp (TestView.elm:1381)
at Function.compare [as func] (TestView.elm:1162)
at A2 (TestView.elm:92)
at Function.func (TestView.elm:3529)
at A2 (TestView.elm:92)
at TestView.elm:9222
at TestView.elm:16
at A2 (TestView.elm:93)
at Function.func (TestView.elm:4006)
at A2 (TestView.elm:92)

If there is a workaround please let me know, i tried to switch to Arrays the problem still remains (maybe because the comparison is done in the DOM part behind the scenes?).

@b0urb4k1 : you're facing a different (non-compiler related) issue, more specifically https://github.com/elm-lang/virtual-dom/issues/80 (tracked in https://github.com/elm-lang/virtual-dom/issues/98)

The current suggestion, until that is fixed, is to turn off the debugger or use a smaller dataset during development.

Thanks for the report!

zwilias · Sep 27, 2017

@b0urb4k1 : you're facing a different (non-compiler related) issue, more specifically https://github.com/elm-lang/virtual-dom/issues/80 (tracked in https://github.com/elm-lang/virtual-dom/issues/98)

The current suggestion, until that is fixed, is to turn off the debugger or use a smaller dataset during development.

Thanks for the report!

Happens to me too on Chrome Version 62.0.3202.94 (Official Build) (64-bit)
Works fine on Edge 40.15063.674.0.

Was trying to create 1058 long list of integers.

Elm 0.18

Janjuks · Dec 5, 2017

Happens to me too on Chrome Version 62.0.3202.94 (Official Build) (64-bit)
Works fine on Edge 40.15063.674.0.

Was trying to create 1058 long list of integers.

Elm 0.18

The root issue seems to be that the generated code represents things faithfully as they will be at runtime. A bunch of nested cons cells.

In my development build, we no longer do the cons representation of the list. Instead, it is a JS array that gets converted at runtime. This is how it was before this issue started appearing, and it is just going back to how it used to be.

evancz · Mar 7, 2018

The root issue seems to be that the generated code represents things faithfully as they will be at runtime. A bunch of nested cons cells.

In my development build, we no longer do the cons representation of the list. Instead, it is a JS array that gets converted at runtime. This is how it was before this issue started appearing, and it is just going back to how it used to be.

rtfeldman referenced this issue Dec 17, 2016
Closed
Importing long list causes "Maximum call stack size exceeded" #146

jvoigtlaender referenced this issue Jan 6, 2017
Closed
Out of Memory error with elm-make (0.18) when compiling large list #1551

rtfeldman added the bug label Jan 8, 2017

jvoigtlaender referenced this issue Feb 25, 2017
Closed
List literal with many items leads to "Maximum call stack size exceeded" #840

This was referenced Feb 25, 2017

Closed

`fromISO8601` fails when date ends with `.000Z` elm-community/elm-time#21

Closed

Time.TimeZones import unusable from elm-reactor v0.18.0 elm-community/elm-time#13

witoldsz referenced this issue Feb 25, 2017
Merged
elm-lang/core#840 workaround issue #13 #22

stephenreddek added a commit to stephenreddek/elmoji that referenced this issue Mar 1, 2017

Split long list into separate lists combined
To address elm/compiler#1521

f9aaa50

stephenreddek referenced this issue Mar 1, 2017
Merged
Split long list into separate lists combined #1

teepark added a commit to teepark/elmoji that referenced this issue Mar 1, 2017

Split long list into separate lists combined (#1)
To address elm/compiler#1521

0881583

amzuko referenced this issue Mar 11, 2017
Closed
v0.6.2 release fails with "maximum call stack size exceeded" #84

pablohirafuji referenced this issue Mar 11, 2017
Closed
Html Character Entities like ` ` do not work #2

evancz added a commit that referenced this issue Mar 30, 2017

Switch back to array literals for list literals, fix #1521

bfae985

magopian referenced this issue Jun 2, 2017
Closed
Very slow loading time, or error messages in the console #92

magopian added a commit to mozilla-services/buildhub that referenced this issue Jun 2, 2017

Fix slow loading times caused by a elm-compiler bug elm/compiler#1521

Loading status checks…

bd65705

n1k0 added a commit to mozilla-services/buildhub that referenced this issue Jun 2, 2017

Merge pull request #93 from mozilla-services/92-fix-slow-loading-times
Fix slow loading times caused by a elm-compiler bug elm/compiler#1521

01aae6f

stil4m referenced this issue Sep 4, 2017
Open
Merge concatenated list literals? #402

Zinggi pushed a commit to Zinggi/elm-hash-icon that referenced this issue Mar 2, 2018

Fixed crash on chrome
caused by elm/compiler#1521

d14e58d

evancz closed this Mar 7, 2018

BTBTravis referenced this issue Apr 23, 2018
Open
Blows Stack on Large Files #5

g-viet referenced this issue Jun 8, 2018
Open
Elm: get div content editable text that including img tag's alt attribute value #4

icidasset referenced this issue Jul 6, 2018
Closed
Scan on Webdav root directory with many files causes "stack size exceeded" error #112

elm/compiler

Join GitHub today

"Maximum call stack size exceeded" with large List #1521

Comments

jinjor commented Nov 30, 2016

This comment has been minimized.

process-bot commented Nov 30, 2016

This comment has been minimized.

jsdw commented Dec 6, 2016

This comment has been minimized.

moore commented Dec 9, 2016

This comment has been minimized.

deepilla commented Dec 11, 2016 • edited Edited 1 time deepilla edited Dec 11, 2016 (most recent)

rtfeldman referenced this issue Dec 17, 2016

jvoigtlaender referenced this issue Jan 6, 2017

rtfeldman added the bug label Jan 8, 2017

This comment has been minimized.

paulswartz commented Jan 14, 2017

jvoigtlaender referenced this issue Feb 25, 2017

This was referenced Feb 25, 2017

This comment has been minimized.

witoldsz commented Feb 25, 2017

witoldsz referenced this issue Feb 25, 2017

stephenreddek added a commit to stephenreddek/elmoji that referenced this issue Mar 1, 2017

stephenreddek referenced this issue Mar 1, 2017

This comment has been minimized.

bamorim commented Mar 1, 2017 • edited Edited 1 time bamorim edited Mar 1, 2017 (most recent)

teepark added a commit to teepark/elmoji that referenced this issue Mar 1, 2017

teepark added a commit to teepark/elmoji that referenced this issue Mar 4, 2017

amzuko referenced this issue Mar 11, 2017

pablohirafuji referenced this issue Mar 11, 2017

evancz added a commit that referenced this issue Mar 30, 2017

This comment has been minimized.

kuon commented May 4, 2017

This comment has been minimized.

bamorim commented May 4, 2017

This comment has been minimized.

kuon commented May 4, 2017

This comment has been minimized.

andys8 commented May 22, 2017

magopian referenced this issue Jun 2, 2017

magopian added a commit to mozilla-services/buildhub that referenced this issue Jun 2, 2017

n1k0 added a commit to mozilla-services/buildhub that referenced this issue Jun 2, 2017

This comment has been minimized.

Steve-OH commented Jun 6, 2017

This comment has been minimized.

kuon commented Jun 6, 2017

This comment has been minimized.

Steve-OH commented Jun 7, 2017

stil4m referenced this issue Sep 4, 2017

This comment has been minimized.

b0urb4k1 commented Sep 27, 2017 • edited Edited 1 time b0urb4k1 edited Sep 27, 2017 (most recent)

This comment has been minimized.

zwilias commented Sep 27, 2017

This comment has been minimized.

Janjuks commented Dec 5, 2017

Zinggi pushed a commit to Zinggi/elm-hash-icon that referenced this issue Mar 2, 2018

This comment has been minimized.

evancz commented Mar 7, 2018

evancz closed this Mar 7, 2018

BTBTravis referenced this issue Apr 23, 2018

g-viet referenced this issue Jun 8, 2018

icidasset referenced this issue Jul 6, 2018

deepilla commented Dec 11, 2016 •

edited

Edited 1 time

deepilla edited Dec 11, 2016 (most recent)

bamorim commented Mar 1, 2017 •

edited

Edited 1 time

bamorim edited Mar 1, 2017 (most recent)

b0urb4k1 commented Sep 27, 2017 •

edited

Edited 1 time

b0urb4k1 edited Sep 27, 2017 (most recent)