Closed Bug 464067 Opened 14 years ago Closed 14 years ago

memory leak while running SVG reftests


(Core :: SVG, defect, P2)






(Reporter: jmaher, Assigned: peterv)



(Keywords: memory-leak, testcase, verified1.9.1)


(2 files)

Attached file 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
 => 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.
Alias: sicking
Product: Firefox → Core
QA Contact: general → general
Component: General → SVG
Flags: in-testsuite+
Keywords: testcase
QA Contact: general → general
Flags: blocking1.9.1?
Summary: memory leak while running reftests → memory leak while running SVG reftests
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.
Whiteboard: [nsDocument (7), nsGlobalWindow (3) leaks]
Peter, this would be good to look into to help us get leak numbers down on tinderbox etc.
Assignee: nobody → peterv
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Attached patch v1Splinter Review
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.
Attachment #349473 - Flags: superreview?(jst)
Attachment #349473 - Flags: review?(jst)
Attachment #349473 - Flags: superreview?(jst)
Attachment #349473 - Flags: superreview+
Attachment #349473 - Flags: review?(jst)
Attachment #349473 - Flags: review+
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 ;-).
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b2pre) Gecko/20081122 SeaMonkey/2.0a2pre] (home, optim default) (W2Ksp4)

SM has same leak with only
# svg/
include svg/reftest.list
Blocks: mlkTests
Depends on: 456414
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.
The bug has a reviewed patch, so people already know what caused it; you don't need to guess.
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.9.1 → mozilla1.9.1b3
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b3pre) Gecko/20081128 Minefield/3.1b3pre] (home, optim default) (W2Ksp4)

Whiteboard: [nsDocument (7), nsGlobalWindow (3) leaks]
Depends on: 469518
No longer depends on: 456414
Keywords: verified1.9.1
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.