Bug 78814

Summary: Memory leaks in SVG filters
Product: WebKit Reporter: Michael O'Rourke <mkorourk>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: UNCONFIRMED    
Severity: Normal CC: krit, roger_fong, thorton, zimmermann
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows 7   
Bug Depends on:    
Bug Blocks: 68469    
Attachments:
Description Flags
Example file none

Michael O'Rourke
Reported 2012-02-16 07:50:23 PST
The attached HTML is a distilled example of far more complex HTML/JS which creates SVG content dynamically including filters. With such content we are experiencing the memory footprint of Chrome infinitely increasing. Within 15 minutes the footprint grows from 24MB to 120MB and continues upward from there. The same problem does not happen in Firefox. Note that in this simplified example, the filter is created but never attached to an SVG object. This was not the case in the original content and is part of the simplification of the original bug. To reproduce, just open the HTML file and then watch the memory footprint of Chrome via Task Manager.
Attachments
Example file (8.24 KB, text/html)
2012-02-16 07:50 PST, Michael O'Rourke 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Michael O'Rourke
Comment 1 2012-02-16 07:50:43 PST
Created attachment 127379 [details] Example file
Nikolas Zimmermann
Comment 2 2012-02-17 01:05:37 PST
Hrm, this is a bit awkward. I've changed your original testcase, to really only create a SVGFilterElement, not appending children, not using DOM/SVG DOM functionality, nothing. When breaking on SVGFilterElement constructor/destructor, it's obvious, that there's no memory leak. The SVGFilterElements are created, and then at some point they get garbage collected. Unfortunately I can't use Instruments, to trace memory-leaks/allocations, as attaching it makes the WebProcess crash (seems a general problem with Instruments, need to investigate...) valgrind also seems to crash on Lion, attaching to eg. DumpRenderTree (hmpf :(). Anyhow, my theory is that we're observing memory fragmentation here. Also new-run-webkit-tests --leaks doesn't detect any leaks, when running your testcase for 20s, which is also a good indicator, that we're not loosing memory.
Michael O'Rourke
Comment 3 2012-02-17 06:44:58 PST
Agreed that with only creating the SVGFilterElement the memory footprint does not continue increasing. Maybe the problem is with the underlying elements added to the filter not getting freed correctly? I tried some experiements with walking the filter child elements and explicitly removing them but this didn't seem to help.
Nikolas Zimmermann
Comment 4 2012-02-17 07:02:23 PST
(In reply to comment #3) > Agreed that with only creating the SVGFilterElement the memory footprint does not continue increasing. Maybe the problem is with the underlying elements added to the filter not getting freed correctly? I tried some experiements with walking the filter child elements and explicitly removing them but this didn't seem to help. Oh, my wording was wrong before. The memory footprint also increases when creating only the SVGFilterElement in my debug build - but that may be mem fragmentation....
Note You need to log in before you can comment on or make changes to this bug.