Bug 78814 – Memory leaks in SVG filters

• Component: SVG
• Status: UNCONFIRMED

[Michael O'Rourke]

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.

[Michael O'Rourke]

Created attachment 127379 [details]
Example file

[Nikolas Zimmermann]

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]

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]

(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....