Issue metadata
Sign in to add a comment
|
infinite loop until memory allocation in v8 crashes the page
Reported by
antoine....@digdash.biz,
Jul 6 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 OPR/46.0.2597.39 Steps to reproduce the problem: 1. go to the following web page: http://tdemo.digdash.com/bugcr59/template/svg/test/test-template.html?template=bar 2.Play with the combo box called "Département" (alternate quickly between "Tous" and another value 3. The page continues to react correctly but if you look at the task manager one CPU is fully used and memory is increasing fast What is the expected behavior? This should not consume CPU and memory ressources What went wrong? infinite loop until memory allocation in v8 crashes the page After looking at chrome://tracing it seems that the memory allocated comes from V8 Did this work before? Yes Previous stable version of chrome Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version: The problem exists in beta channel (60.0.3112.50)
,
Jul 7 2017
As per the bisect provided in comment #1 adding @hablich for more updates on this issue. Note: Adding RB-Stable for M-60 please feel free to edit if this is not the case. Thanks!
,
Jul 10 2017
on-duty memory sheriffs, please investigate.
,
Jul 10 2017
,
Jul 10 2017
Benedikt, could you have a look? Reliably bisected to [385734bf11d3c4529cc30c553eef8c3e0d69afad] [turbofan] Let ChangeFloat64ToTagged canonicalize to Smi if possible. V8's malloc-ed memory is rising. Trace is attached. Last line --trace-turbo shows: Begin compiling method BarChart.draw using Turbofan Could not reproduce on chrome ToT 3eb6363c61b669b65ff723f113f5190eb54dc4e4. Maybe some backmerge missing?
,
Jul 11 2017
Attached: --trace-turbo-graph log Chromium rev: f18a21249a7387a73cbc1c4a7357d5f4971ce42f
,
Jul 12 2017
Looks like e04f33ad6f563f61ae1613e71c2c33e7f0451a03 fixes the problem, which corresponds to the fact that it hangs on LateOptimizationPhase. Mythri can you take a look?
,
Jul 12 2017
Yes, that fixes it. BarChart.draw is a very large function, and there are lot of revisits which increases the memory in LateOptimizationPhase. The behaviour is same as what I saw in this bug: crbug.com/725664 . I verified that if I revert that change I can reproduce the problem.
,
Jul 12 2017
I guess this is fixed now. Benedikit, Is there anything else you wanted me to look at?
,
Jul 12 2017
Did all the patches make it into a backmerge? #0 mentions that this also happens on beta.
,
Jul 12 2017
hablich@ could you approve e04f33ad6f563f61ae1613e71c2c33e7f0451a03 for merge to M60
,
Jul 12 2017
This bug requires manual review: We are only 12 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 12 2017
,
Jul 12 2017
mythria@ perfect, thanks!
,
Jul 12 2017
,
Jul 13 2017
I forgot to update the bug id in the merge. This is the merge commit: 54d17081353eff895fa15de06be893b9f042a78c
,
Jul 13 2017
This is the cl: https://chromium-review.googlesource.com/c/568558/
,
Jul 14 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by woxxom@gmail.com
, Jul 6 2017