I can give an access to an hubspot test site to let someone debug the issue

This bug does not have a Crash ID!  These logs are key to figuring out what went wrong.  Please go to chrome://crashes and look up an ID.

But it does not crash. It stop rendering the page after the javascript error.
59xxxx is now stable and all of our chromebook cannot use Hubspot anymore.

Thank you for providing more feedback. Adding requester "rjahagir@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We can drop all our 12 chromebooks in the trash can

This is the error:
https://www.useloom.com/embed/0d4dda441f364f6b8941d0b33af8b8db

It work on every other version of chrome but not in the lastone on chromeos.

I want to add that on chromeos dev channel 60.0.3112.26 it work correctly

Thanks for clarifying

We have tracked down the issue here to UglifyJS creating sequences that were too long for Chrome to handle. (https://github.com/mishoo/UglifyJS2/issues/1038). 

The only version of chrome that we could track that would hit this issue was Chrome OS 59 64 bit. Chrome OS 59 32 bit was unaffected. 

https://static.hsappstatic.net/crm_ui/static-2.2036/coffee/crm-vendor.js was the file that was failing to parse. 

Removing Blink>Infra>Predictability component, as this seems to be an issue with a specific version of Chrome (on ChromeOS), as opposed to a web platform predictability problem.

Given that this is reported as a regression in M59, I think this is likely another case of Ignition requiring more stack space. Assigning to Ross for further triage.

In my project we experienced an unfortunate issue because of the reduced number of recursive calls possible.

Our client would simply stop working when upgrading chrome. This has happened twice within the last year. First time around November 2016 and then again when this issue was originally reported in May.

The root cause of our issue was string concatenation, our client is a big angular app, where we have had all the our html templates bundled as strings within a javascript file. In order to make it all readable line breaks was preserved and string concatenation was used.

Example:
"<div>\n" + 
"  {{model.value}}\n" +
"</div>"

We now do not concatenate any more but keep it as one long string this has resolved our issue.

Our conclusion to this has been that this is caused by the internal implementation of the + operator being recursive, with no tail recursive optimisation.

The issue is easy to reproduce with the code snippit below, just paste it into a developer console:


var str = "'-1";
for(var i = 0; i < 10000; i ++) {
  str += "' + '" + i;
}
str += "'";
eval(str);


We also did try to count how many recursive calls could be made from chrome 58 and 59.

58 could do about 20000 where 59 could only do about 10000.

I hope this helps clarify.

I also hope that you could implement a test that would verify that the number recursive calls possible does not decrease further.

Even though you could argue if it is a good ide for an application to be implemented with this many recursive calls it is still a very sudden breaking change that in our case was hitting software already shipped to customers, beyond our reach.

Hi Stefan,

You're absolutely right that this is a regression, and it's an unfortunate one because it does mean breaking code that is unlucky enough to fit into the old stack size limits but not the new ones. We did ship some improvements in M61 (specifically https://chromium-review.googlesource.com/#/c/541356/, see also the bugs https://bugs.chromium.org/p/chromium/issues/detail?id=731861 and https://bugs.chromium.org/p/chromium/issues/detail?id=752081), so these should improve things, and we do have unit tests for this tracking any regressions (https://cs.chromium.org/chromium/src/v8/test/js-perf-test/ExpressionDepth/run.js), but fundamentally Ignition is a necessarily different compiler to FullcodeGen, and it needs the extra stack space. Even if we were to (somehow) match the old stack limit, there's no way that we can guarantee that we can maintain it across releases -- for example, the JS spec could change in a way that requires us to keep more state during the AST traversal.

That said, this particular case of templates consisting of string concatenations does seem to come up a lot. I've started looking into parsing these chained adds differently: https://bugs.chromium.org/p/v8/issues/detail?id=6964.

Thank you Leszeks for the information.
I was happy to read the tests, and I will follow the progress of https://bugs.chromium.org/p/v8/issues/detail?id=6964&desc=2

Keep the good work :)

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/52ef2a1c270e612906936d64419c335d62fc5822

commit 52ef2a1c270e612906936d64419c335d62fc5822
Author: Leszek Swirski <leszeks@chromium.org>
Date: Wed Oct 25 11:28:55 2017

[parser] Add an n-ary node for large binop chains

Expressions of the form

    a_0 + a_1 + a_2 + a_3 + ... + a_n

seem to be reasonably common for cases such as building templates.
However, parsing these expressions results in a n-deep expression tree:

           ...
          /
         +
        / \
       +  a_2
      / \
    a_0 a_1

Traversing this tree during compilation can cause a stack overflow when n is
large.

Instead, for left-associate operations such as add, we now build up an
n-ary node in the parse tree, of the form

         n-ary +
       /  |      \
      /   |  ...  \
    a_0  a_1      a_n

The bytecode compiler can now iterate through the child expressions
rather than recursing.

This patch only supports arithmetic operations -- subsequent patches
will enable the same optimization for logical tests and comma
expressions.

Bug:  v8:6964 
Bug:  chromium:724961 
Bug: chromium:731861
Bug:  chromium:752081 
Bug:  chromium:771653 
Bug: chromium:777302
Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb
Reviewed-on: https://chromium-review.googlesource.com/733120
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48920}
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/ast/ast-expression-rewriter.cc
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/ast/ast-numbering.cc
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/ast/ast-traversal-visitor.h
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/ast/ast.h
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/ast/prettyprinter.cc
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/interpreter/bytecode-array-builder.h
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/interpreter/bytecode-generator.cc
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/interpreter/bytecode-generator.h
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/parsing/parser-base.h
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/parsing/parser.cc
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/parsing/parser.h
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/parsing/pattern-rewriter.cc
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/src/parsing/preparser.h
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/test/cctest/interpreter/bytecode_expectations/AssignmentsInBinaryExpression.golden
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/test/cctest/interpreter/bytecode_expectations/StringConcat.golden
[add] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/test/mjsunit/compiler/nary-binary-ops.js
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/test/unittests/compiler-dispatcher/compiler-dispatcher-unittest.cc
[modify] https://crrev.com/52ef2a1c270e612906936d64419c335d62fc5822/test/unittests/compiler-dispatcher/unoptimized-compile-job-unittest.cc

This should work now, so you'll see it in M64.

$ cat test.js
var str = "'-1";
for(var i = 0; i < 50000; i ++) {
  str += "' + '" + i;
}
str += "'";
print(eval(str).length);

$ d8 test.js
238892