Bug 78814 - Memory leaks in SVG filters
Summary: Memory leaks in SVG filters
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 68469
  Show dependency treegraph
 
Reported: 2012-02-16 07:50 PST by Michael O'Rourke
Modified: 2014-03-02 10:12 PST (History)
4 users (show)

See Also:


Attachments
Example file (8.24 KB, text/html)
2012-02-16 07:50 PST, Michael O'Rourke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael O'Rourke 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.
Comment 1 Michael O'Rourke 2012-02-16 07:50:43 PST
Created attachment 127379 [details]
Example file
Comment 2 Nikolas Zimmermann 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.
Comment 3 Michael O'Rourke 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.
Comment 4 Nikolas Zimmermann 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....