464067 - memory leak while running SVG reftests

Status: VERIFIED FIXED

(Core :: SVG, defect, P2)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: full memory leak log

While running reftests (firefox -reftest src/layout/reftests/svg/reftest.list), I encounter a memory leak:

   0 TOTAL                                          40   350435   106535    10784 (  432.26 +/-   632.38)   316755     7203 (  325.72 +/-   562.87)
 

nsTraceRefcntImpl::DumpStatistics: 559 entries
nsStringStats
 => mAllocCount:           8381
 => mReallocCount:          507
 => mFreeCount:            6809  --  LEAKED 1572 !!!
 => mShareCount:           8346
 => mAdoptCount:            790
 => mAdoptFreeCount:        788  --  LEAKED 2 !!!



This was found originally while testing fennec, but looking for parity in firefox resulted in the same leak.

There are actually 4 tests which leak (create a leak.list and run it instead of reftest.list):
mozilla@mozilla-desktop:~/mozilla/src$ cat layout/reftests/svg/leaks.list 
== dynamic-clipPath-01.svg pass.svg
== dynamic-use-01.svg pass.svg
== use-01-extref.svg pass.svg
== use-02-extref.svg use-02-extref-ref.svg


It could be that each of these are seperate leaks.  You can comment out any of these reftests using a # if you want to test each individual.  Since these are in the same area, I am going to lump them together.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I found pretty much the same thing today (and a few other leaks) using leak-gauge, which is a much quicker way to isolate which tests are causing the leaks.

Comment 2

[Johnny Stenback (:jst)]

Peter, this would be good to look into to help us get leak numbers down on tinderbox etc.

Comment 3

[Peter Van der Beken [:peterv]]

Attachment: v1

Pfff, this took me a while to figure out. nsSVGUseElement wasn't returning the participant in its QI implementation, so we always used the base class' participant and thus there were missing edges. I looked through the tree for other classes with a similar problem, nsXTFElementWrapper looks like the only other.

Comment 4

[Peter Van der Beken [:peterv]]

Jesse asked if we could have assertions to catch this. I've been thinking about ways to catch this at compile or at runtime, but haven't come up with anything yet. The place to assert would be the QI implementation that was missing a macro, so that's not really a solution ;-).

Comment 5

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081122 SeaMonkey/2.0a2pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/5d37678a2482
+http://hg.mozilla.org/comm-central/rev/892e9f783d9e)

(Confirming:)
SM has same leak with only
{
# svg/
include svg/reftest.list
}

Comment 6

[Serge Gautherie (:sgautherie)]

I wonder if this is some kind of regression, or new tests, as it seems I didn't see it at bug 458844 comment 3 time.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The bug has a reviewed patch, so people already know what caused it; you don't need to guess.

Comment 8

[Shawn Wilsher :sdwilsh]

http://hg.mozilla.org/mozilla-central/rev/2ba4924ee82e

Comment 9

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20081128 Minefield/3.1b3pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/2ba4924ee82e)

V.Fixed