Parsing long concatenated Javascript string causes rangeerror
Reported by
roeland....@gmail.com,
Jan 2 2017
|
||||||||||||||||||
Issue description
Chrome Version : 55.0.2883.87 m (64-bit), same on 32-bit Chrome
URLs (if applicable) :
Other browsers tested:
Safari:
Firefox: 50.1.0 OK
IE: Edge 12 OK
IE: 11 OK
What steps will reproduce the problem?
(1) Load HTML with large concatenated Javascript string
(2) Console reports RangeError when number of lines concatenated is above approx. 1700. Firefox and IE can handle more than 4000 lines.
Reproduction:
<script>
var jsonstr = '{"list0": ['
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
...
...
+ '{"sruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335933.243797", "ouid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.89803", "pruid": ""}'+ ','
+ '{"sruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335933.243797", "ouid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.277389", "pruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.277389.89067236.234.56.5678.8886757646"}'
+ '],'
+ '"imgcnt": "361",'
+ '"suid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340334814.340258",'
+ '"prsruid": "" '
+ '}';
</script>
What is the expected result?
Valid Javascript
What happens instead?
Uncaught RangeError: Maximum call stack size exceeded
Please provide any additional information below. Attach a screenshot if
possible.
,
Jan 4 2017
,
Jan 4 2017
Could you please help providing the sample html file as when tried the below getting syntax error as :"ncaught SyntaxError: Unexpected token ...".
<html>
<body>
<script>
var jsonstr = '{"list0": ['
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
...
...
+ '{"sruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335933.243797", "ouid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.89803", "pruid": ""}'+ ','
+ '{"sruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335933.243797", "ouid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.277389", "pruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.277389.89067236.234.56.5678.8886757646"}'
+ '],'
+ '"imgcnt": "361",'
+ '"suid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340334814.340258",'
+ '"prsruid": "" '
+ '}';
</script>
</body>
</html>
,
Jan 4 2017
Syntax error is caused by ellipsis halfway down code sample. I did this so as not to have to paste in 2,000 lines of code. T reproduce problem, just replicate a line until total number of lines exceeds 1,700.
Below is parseable code sample, a longer code sample that reproduces error is in attachemnt LongTest.html:
<html>
<body>
<script>
var jsonstr = '{"list0": ['
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "", "ouid": "", "pruid": ""}'+ ','
+ '{"sruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335933.243797", "ouid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.89803", "pruid": ""}'+ ','
+ '{"sruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335933.243797", "ouid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.277389", "pruid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340335954.277389.89067236.234.56.5678.8886757646"}'
+ '],'
+ '"imgcnt": "361",'
+ '"suid": "1.2.392.200036.9116.2.6.1.48.1214833951.1340334814.340258",'
+ '"prsruid": "" '
+ '}';
</script>
</body>
</html>
,
Jan 6 2017
,
Jan 6 2017
What is nature of request in comment 5? It appears blank.
,
Jan 6 2017
Yes, tested this issue on Ubuntu 14.04 using chrome latest stable M55-55.0.2883.87. By opening the "LongTest.html" file from comment #4, Observed a blank page and no errors printed under dev console. By opening the same html file in Firefox, observed some error as shown in the below screen-shot. roeland.lasure@ Could you please confirm is this is the issue you are talking about? Thanks!
,
Jan 6 2017
Windows 7, Chrome 57.0.2973.0 (Official Build) canary (64-bit): I see "Uncaught RangeError: Maximum call stack size exceeded" for LongTest.html in #4 but not in the chromium snapshots [1] (these are used by the bisect-builds.py script so bisecting is impossible for me). [1]: https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/
,
Jan 9 2017
Please recheck with an pre Chrome 55 version in order to find out if this is a regression.
,
Jan 9 2017
,
Jan 11 2017
Able to reproduce this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome latest canary #57.0.2977.0 and Beta #56.0.2924.51. It's working fine on latest stable M55-55.0.2883.87. Note: Unable to invoke bad builds during per revision bisect and chromium bisect. Hence providing manual CL below from omahaproxy. Bisect information: -------------------- Good build:56.0.2897.0 Bad build: 56.0.2898.0 Change log from omahaproxy: https://chromium.googlesource.com/chromium/src/+log/56.0.2897.0..56.0.2898.0?pretty=fuller&n=10000 From the CL above, assigning the issue to the concern owner Review-Url: https://chromiumcodereview.appspot.com/2441853002 chrishtr@ - Observing some changes related to runtime, Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Adding RB-Stable since this is a recent regression, feel free to edit if this is not the case. Thanks!
,
Jan 11 2017
It was not my CL. It was one of the v8 rolls. Marking as untriaged to get picked up by the v8 team.
,
Jan 16 2017
The only relevant change in the range is https://chromium.googlesource.com/v8/v8/+/cadfe092a25fd052294a45a2c5aabe34b475f534.
,
Jan 16 2017
,
Jan 17 2017
@hablich: My change only affects a feature that is not yet shipping.
,
Jan 17 2017
Could someone from v8 team look into this please.
,
Jan 17 2017
,
Jan 17 2017
+current v8 stability sheriff
,
Jan 18 2017
Bmeurer@ didn't we route a bunch of stuff through Ignition+TurboFan starting with 56? That might explain the change in behavior?
,
Jan 18 2017
Yes, so maybe BytecodeGenerator causes stack overflow. Definitely not TurboFan, as all of this goes through the BytecodeGraphBuilder then, which cannot throw RangeErrors. This requires proper triaging/bisecting. Assigning back to hablich@ to find the appropriate sheriff/owner.
,
Jan 18 2017
FWIW, by setting a breakpoint for the "Maximum call stack size exceeded" message in a debugger attached to the tab process, and stepping through the code prior to the exception, I see it occurs in FullCodeGenerator::MakeCode, specifically inside arch-specific cgen.Generate(), which is too arcane for me to decipher: https://chromium.googlesource.com/v8/v8.git/+/refs/heads/5.7.492/src/full-codegen/full-codegen.cc#110 Tested on Chromium 57.0.2985.0 (Official Build) canary (64-bit), r444244
,
Jan 19 2017
The problem here is that the baseline compilation in V8 runs out of stack space (in my debugging session it was in the ast-numbering). V8 uses a RangeError to communicate this V8-internal stack overflow to the JS developer. The RangeError does not indicate in this case that the JavaScript code is invalid, it just cannot be compiled by V8. As far as I can see V8 is working as intended here.
,
Jan 20 2017
>Status: WontFix Does it mean Chrome failing on long concatenated strings is perfectly fine?
,
Jan 23 2017
Coincidentally, this is a recent v8 side bug for the exact same issue: https://bugs.chromium.org/p/v8/issues/detail?id=5793 Fixing the ultimate cause would mean redesigning the parsers & compilers so that they don't recurse when parsing & compiling constructs like these. Firefox is doing much better than Chrome - it is able to handle at least ~500K concatenated items; Chrome cannot even handle 8K. However, we could look at: - Parser rewriting such constructs statically. We'd still bump into the same problem with other similar constructs - but maybe it's good enough for practical purposes. - Increasing the stack space V8 can use (not sure how conservative we are on mobile). Also will not help against the actual cause...
,
Jan 23 2017
Regarding stack space on mobile - we use the same stack limit on mobile as desktop (1MB). We could increase it on both, however that would need corresponding increases in the stack space allocated for each background thread in Chrome, which might be an issue.
,
Jan 23 2017
re #23: Just to make it clear, the issue is not concatinating large strings, the issue is the there is a single statement with thousands of '+' expressions, all of which are nested. Rewriting the JS code to the following:
var jsonstr = '{"list0": [';
jsonstr += '{"sruid": "", "ouid": "", "pruid": ""}'+ ',';
jsonstr += '{"sruid": "", "ouid": "", "pruid": ""}'+ ',';
jsonstr += '{"sruid": "", "ouid": "", "pruid": ""}'+ ',';
jsonstr += '{"sruid": "", "ouid": "", "pruid": ""}'+ ',';
...
Would avoid the issue entirely.
,
Jan 24 2017
#26, there are many workarounds, but the official comment "As far as I can see V8 is working as intended here" followed by the wontfix status is just... weird. It reminds me of the '90s when 640kB was the limit. The OP's code works in previous versions of Chrome and other browsers just fine, and it's 2017 now.
,
Jan 24 2017
re #25: Increasing the stack space would also help with some Blink crashes involving deeply nested DOM structures and recursive algorithms in style or layout. What would be the likely downsides? Address space exhaustion on 32 bit platforms? |
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by sigbjo...@opera.com
, Jan 3 2017