274925 - Native SVG (win32 GDI) leaks 2 GDI objects per SVG page reload

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Norm Petterson]

Using the native SVG win32 GDI Firefox build downloaded this week (12/14/2004)
from mozilla.org to view, for example, a local copy of croczilla's tiger.svg, an
obvious memory leak can be demonstrated by repeatedly reloading the same page.
Using Windows Task Manager, two GDI objects (and one USER object) are left in
use at each reload, and after around 600 reloads, for instance, nearly 200MB of
virtual memory is consumed.

Displaying cache usage via about:cache shows only a handful of gif files (and
apparently none of the objects implicated above), so this leak does not appear
to be related to bug# 213391.

Occasionally during the repeated page reloading, GDI Objects appears to increase
by 5 and then decrease by 3 (resulting as above in a net leak of 2 objects).
This might happen every reload but not always be visible due to Task Manager
display timing.

This bug is critical for long-running embedded dynamic SVG applications, and can
be duplicated with native SVG Firefox, mfcembed, and mozctlx ActiveX control.

Comment 1

[Jonathan Watt [:jwatt]]

CCing Alex since this may be important for croc-math.

Does this leak only occur for *local* copies of the file? How are you using the
Task Manager to determine that two GDI "objects" and one USER "object" are being
leaked? Do you mean "processes"? Or does WinXP's Task Manager do something that
Win2k's doesn't?

Comment 2

[Norm Petterson]

Clarifications:

1) The leak occurs consistently on both a local copy of tiger.svg as well as
web-server served copies. Using mfcembed.exe, mozctlx.dll programmatically, or
Firefox itself, approximately 600 reloads of tiger.svg consume around 200MB
virtual memory on Win2K and/or XP.

2) The leaked GDI and USER objects appear on both Win2K and XP Task Manager
columns (when selected as columns to View) consistently using mfcembed.exe as
above. Additional tests just run with Firefox itself and with my own embedded
mozctlx leak the same, but *do not* show accumulated GDI and USER objects. So,
the GDI and USER object leakage consistently appearing with mfcembed is probably
a red herring. (Sorry -- perhaps this bug should be renamed simply "Native SVG
win32 GDI memory leak").

To confirm the memory leak, simply browse tiger.svg locally or directly at
croczilla with the win32-svg-GDI browser (mfcembed, Firefox, or mozctlx) and
patiently hit reload repeatedly for several minutes. Virtual memory (another
Task Manager column not enabled by default) grows fast enough to watch, and does
not appear to ever be reclaimed... Long-running SVG displays need to update for
longer than ten or twenty minutes before consuming all the virtual memory on a
production machine!

Comment 3

[Norm Petterson]

The article http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/ suggests
that it is non-trivial to track GDI object usage, particularly when objects are
created by DLLs rather than by mainline application code. 

Possibly the object leakage information only viewable when using mfcembed.exe
*is* indicative of the cause of this leak.

Comment 4

[Norm Petterson]

Attachment: XPCOM_MEM_LEAK_LOG log after single display of Tiger.svg

This attachment demonstrates the XPCOM_MEM_LEAK_LOG memory leak log produced by
a single display of the croczilla tiger.svg file, and appears to indicate that
the memory leak is not specific to the Win32 GDI+ renderer.

Comment 5

[Norm Petterson]

Attachment: XPCOM_MEM_LEAK_LOG log after display and 2 reloads of Tiger.svg

Another XPCOM_MEM_LEAK_LOG memory leak log, after initially loading and then
reloading tiger.svg twice.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Norm, what's the smallest SVG document that still triggers this leak?

Comment 7

[Norm Petterson]

Not sure about the smallest SVG document, but suspect from the attached mem leak
lists that *all* SVG processing of certain elements leak. Note for instance that
all nsSVGPathSegList objects are never freed, and that the most apparent leakage
is due to nsSVGPathSegCurvetoCubicAbs objects never being deallocated. I suspect
that the never-deallocated nsSVGAnimatedRect objects might be a clue, and don't
know what to make of the seemingly over-deallocated nsSVGRect objects (but am
still a newbie at memory leak tracing ;-). I'm still working on it.

Incidentally, this bug is *definitely* titled incorrectly; the same repeated
reloading of the same SVG image using the Linux version of native Mozilla SVG
leaks even worse. Thirty reloads of tiger.svg consumes 20MB of virtual memory on
my Debian Linux system.

Why the question about the smallest SVG file? I can try any minimal file you'd
like (just attach here) with the leak detection turned on...

Comment 8

[tor]

All attribute objects are leaking - I'm looking into it.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> that *all* SVG processing of certain elements leak.

The question is _which_ elements.  Knowing that will give a starting place for
where to look in the code...

Comment 10

[Alex Fritze]

Attachment: fix for nsAttrValue/nsISVGValue leaks

This should fix leaks of svg mapped attributes.

Comment 11

[tor]

Attachment: get rid of pre-refcounted classes

These caused the XPCOM leak checker problems.

Comment 12

[tor]

refcounting patch checked in - waiting for sr on the leak fix.

Comment 13

[Johnny Stenback (:jst)]

Comment on attachment 171672 [details] [diff] [review]
fix for nsAttrValue/nsISVGValue leaks

sr=jst

Comment 14

[Alex Fritze]

nsAttrValue patch checked in.

Comment 15

[Jonathan Watt [:jwatt]]

Is everything checked in that should have been? If so can we mark this fixed/wontfix since we have no plans to continue development of the GDI+ backend?

Comment 16

[Jonathan Watt [:jwatt]]

So both patches were checked in, the task manager shows no increased in GDI objects across reloads, and using XPCOM_MEM_LEAK_LOG shows no obviously SVG related leaks. Closing as fixed.