Memory leak when manipulating svg transformations
Reported by
ped...@gmail.com,
Jun 14 2016
|
||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36
Steps to reproduce the problem:
1. Load attrleak.html or/and attrleak2.html
2. Clcik on "Create SVG Button"
3. Clcik on "Start"
4. Wait and see the memotry usage in the task manager
What is the expected behavior?
After 2 hour the memory usage should be under 20Mb, as it is with the attrleak3.html. In the html file the svg is not manipulated.
What went wrong?
attrleak.html and attrleak2.html creates a small svg animation.
attrleak.html sets an svg tranform for a group:
group.setAttribute("transform", svgtransform);
attrleak2.html sets a transformation matrix:
group.transform.baseVal.initialize(svgroot.createSVGTransformFromMatrix(matrix));
After 2 hours the memory usages are above than 49Mb. (it leaks ~18Mb/hours)
After a week it could crashes the browser.
Did this work before? N/A
Chrome version: 51.0.2704.84 Channel: stable
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0
,
Jun 15 2016
Unable to reproduce the issue on Windows 7 using 51.0.2704.84, latest canary 53.0.2768.0 as per above steps.Observed that after 2 hours the memory usage is under 20MB. Please find attached screencast. pedigs@Could you please check the issue on clean profile and update the thread if issue still persists.
,
Jun 16 2016
I tried on a Windows 7 machine using 51.0.2704.84 and latest canary 53.0.2768.0. I could reproduce the issue only when Chrome is not minimized. If the chrome was minimized onto the taskbar or the animation was not on the active tab, the issue does not occure. ssamanoori@Could you please rerun the animation with displayed and active chrome windows (as it is shown in the attached screenshot).
,
Jun 17 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
,
Jun 20 2016
,
Jun 27 2016
,
Jun 28 2016
I've been running attrleak.html and attrleak2.html for a number of hours (the latter over night), and not observed any runaway memory usage. The transform objects (SVGTransform) that gets allocated by the operations used in the test are GCed and the behavior I've observed are what one would expect under those circumstances (i.e "sawtooth" shaped; growth and then some memory gets collected). attrleak2.html will use more memory because if also involves/allocates V8 wrapper objects (this also means two collectors are involved.) This is all on recent trunk.
,
Jul 1 2016
This issue has been tested on numerous machines several times by different people, and it always happens for everyone. It is very important to follow the guidelines (webpage has to be visible at all times, you can't minimize your browser, put it in the background or switch tabs) - but if you do, you will see it is leaking quite heavily. Our main use-case is to leave the browser running and on top for weeks, so it is very important for us to get this fixed.
,
Jul 1 2016
,
Jul 1 2016
If you do any one of those things you mention: * "minimize your browser" * "put it in the background", or * "switch tabs" do you then see the memory usage drop instantly back to something roughly the "start value"? If so, this makes it sound like the leak may related to some resource in the display stack. The fact that it doesn't reproduce in a VM, does suggest that display configuration might matter, so do you know how much variation there are in the "numerous machines"? Same OS/version (both Win7 and Win10 are mentioned above)? Same/similar HW configuration? HW acceleration or not? If you know of a version where you can't reproduce (M50?), that could also prove useful (at least eventually, when we're able to reproduce.) If this is very important to get fixed, you can consider trying old builds to see if you can narrow down the window when it first occurred.
,
Jul 1 2016
If I minimize the browser the memory usage doesn't drop back, just doesn't grow further.
,
Jul 1 2016
Ok. If you "multiply" the animation, then does the memory usage grow faster (by roughly the same multiplier)?
,
Jul 2 2016
Thank you for providing more feedback. Adding requester "fs@opera.com" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 6 2016
I tried the animations with setinterval 2 and 20 ms. After a day the memory usages were: attrleak (2ms): 380MB attrleak (20ms): 330MB attrleak2 (2ms): 400MB attrleak2 (20ms): 340MB Note: Mostly we try with integrated intel video card, but the bug occured on a machine with NVidia Video card also.
,
Jul 6 2016
,
Jul 6 2016
So update frequency does have some impact. I still wonder if more animations (animated elements) accelerate the leak.
,
Jul 7 2016
I run 3 test for 5 hours: 1. (original - transform the svg group (conatins 3 graphic, one image and two shapes)): 92MB 2. (transform the 3 graphic object separately): 76MB 3. (transform two same groups (each of them contain the three graphic)): 102MB
,
Jul 7 2016
(For chromium developers) There's been some memory infra work that may make debugging this easier: https://chromium.googlesource.com/chromium/src/+/master/components/tracing/docs/memory_infra.md
,
Jul 14 2016
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by ped...@gmail.com
, Jun 14 2016