Maximum call stack size exceeded on Windows 52 64 bit after running high volume of nested if statements
Reported by
st...@riichard.com,
Aug 1 2016
|
||||||||||
Issue descriptionChrome Version : 52.0.2743.82 m (64-bit) URLs (if applicable) : https://gist.github.com/riichard/9d39a6fa19d7460c9f4b6d06aca4a3a5 Other browsers tested: Add OK or FAIL, along with the version, after other browsers where you have tested this issue: Safari: Firefox Ubuntu: OK 39.0 Chrome Ubuntu: OK Version 49.0.2623.87 (64-bit) Chrome x86 Windows: OK 52.0.2743.82 m (x86) IE: OK 11.0.9600.18314 (edge mode) What steps will reproduce the problem? (1) Run the code in the following code attached which creates 1000 nested if statements. Also available at https://gist.github.com/riichard/9d39a6fa19d7460c9f4b6d06aca4a3a5 What is the expected result? A console log of an integer 500 What happens instead? Uncaught RangeError: Maximum call stack size exceeded Please provide any additional information below. Attach a screenshot if possible.
,
Aug 2 2016
Tested the issue on Windows 7, Mac 10.11.5, Ubuntu 14.04 using 52.0.2743.82, latest canary 54.0.2816.0 with below steps: 1.Opened UR: https://gist.github.com/riichard/9d39a6fa19d7460c9f4b6d06aca4a3a5 2.Navigated to dev tools->console. 3.Not observed any errors in console. Please find attached screenshot and update if anything missed here in triaging the issue. stdin@Could you please provide actual and expected behavior screenshot for further triaging the issue.
,
Aug 2 2016
,
Aug 2 2016
@ssamanoori Could you copy the code that is in the gist, and evaluate it in the console? Also, are you running the 64bit version on Windows 7? I didn't experience the issue in the x86 version.
,
Aug 3 2016
@durga.behera Do you see the red 'Maximum call stack size exceeded'? As specified, it fails in evaluating the code above to load the function, not when running the function foo.
,
Aug 5 2016
,
Aug 13 2016
Thank you for providing more feedback. Adding requester "ssamanoori@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 25 2016
Able to reproduce the issue on Windows 7, Mac 10.11.6, Ubuntu 14.04 using 52.0.2743.82, latest stable 52.0.2743.116 as per comment #4. This is regression issue broken in M-50. Please find below bisect info: Last good build:50.0.2624.0 First bad build:50.0.2625.0 CHANGE LOG URL: https://chromium.googlesource.com/chromium/src/+log/50.0.2624.0..50.0.2625.0?pretty=fuller&n=10000 Unable to find suspect from above CL.Hence, marking it as untriaged. Could anyone from dev team look into this issue and assign it to an appropriate dev person.
,
Aug 29 2016
V8 range: https://chromium.googlesource.com/v8/v8/+log/4.9.385..4.10.6 What is the real world use case for this construct?
,
Aug 29 2016
,
Aug 29 2016
There is no practical use case for such a construct, and if you do, you'll need to re-factor your code. But let me explain how I discovered the problem: My team had created CI jobs that threshold releases based on code coverage, and that people work around that rule by creating complex code to gain code coverage and pass that bar. The code is already removed, but I found the bug very interesting. I do not support this behavior. The code coverage threshold is also removed.
,
Aug 29 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 31 2017
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by st...@riichard.com
, Aug 1 2016