Maximum call stack size exceeded while parsing generated code

[Iain Gray]

I'm having a strange problem and was wondering if anyone had any suggestions on how to pinpoint what is causing it.

I have an Elm app that compiles in 0.18, but the generated javascript code is throwing a "RangeError: Maximum call stack size exceeded" as soon as the javascript file is loaded into Chrome. I do not have this problem in Firefox, but I can reproduce it in nodejs/esprima as follows:

var esprima = require('esprima');
var fs = require('fs');
var filePath = path.join('.', 'elm.js');

fs.readFile(filePath, 'utf8', function(err, data) {
  console.log(esprima.parse(data));
});

RangeError: Maximum call stack size exceeded
    at isKeyword (.../node_modules/esprima/esprima.js:359:23)
    at scanIdentifier (.../node_modules/esprima/esprima.js:729:20)
    at advance (.../node_modules/esprima/esprima.js:1573:21)
    at lex (.../node_modules/esprima/esprima.js:1691:78)
    at expect (.../node_modules/esprima/esprima.js:2521:21)
    at parseObjectInitializer (.../node_modules/esprima/esprima.js:3047:9)
    at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
    at parsePrimaryExpression (.../node_modules/esprima/esprima.js:3247:20)
    at inheritCoverGrammar (.../node_modules/esprima/esprima.js:2681:18)
    at parseLeftHandSideExpressionAllowCall (.../node_modules/esprima/esprima.js:3414:20)

If I start node with --stack-size=1200, I no longer get the error and esprima can successfully parse the code. Unfortunately, I can't seem to do this with Chrome. I tried:

  <script type="text/javascript">
    Error.stackTraceLimit = 1200;
    var js = document.createElement("script");
    js.type = "text/javascript";
    js.src = './elm.js';
    document.body.appendChild(js);
  </script>

... which doesn't seem to change anything.

I've been commenting out different sections of my code in an attempt to see what part is ultimately causing this, but that has been pretty painful. If anyone has any suggestions, I'd love some advice.

Thanks,

Iain

[Nick Hollon]

I have run into this before. It can be caused by runaway recursion. Can you share your Elm code with us?

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Richard Feldman]

Is this true only when the debugger is running? I've heard of people hitting this when the debugger is running (e.g. in elm-reactor, which always has the debugger running) but not so much with a plain old elm-make.

[Nick H]

In my case, a recursive function was written in such a way that it couldn't benefit from tail-call optimization. It was in 0.17. That was the only time I've encountered the error.

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscribe@googlegroups.com.

[Iain Gray]

It turned out to be an instance of this. I have a list of time-zones that I use for a drop-down list, which was big enough to cause the stack overflow. As the issue-poster mentioned, I was able to fix it by splitting my list into multiple pieces and List.concat'ing them together.

Thanks for the suggestions everyone!

[Nick H]

Glad you found a solution!

[Paul D]

I hit the same problem after updating my project from 0.17 to 0.18. Breaks in Chromium (with or without debug mode), works in Firefox.

My list has 650 items. I wouldn't expect to be hitting any upper limits with a list of that size. Breaking it up into smaller lists seems like more of a workaround than a long term solution. Does anyone know what the underlying issue is and why it seems to be more prevalent in 0.18?

To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.