Closed Bug 473548 Opened 11 years ago Closed 11 years ago

leak 2 nsDisplayBackground when running each 411585-*.html reftest in bugs/reftest.list

Categories

(Core :: Printing: Output, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1b3

People

(Reporter: sgautherie, Assigned: dbaron)

References

Details

(Keywords: fixed1.9.1, memory-leak)

Attachments

(2 files)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090114 Minefield/3.2a1pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/e0ed5852481a)

After fixing the nsMathMLContainerFrame leak of bug 458844,
its (6) nsDisplayBackground leak remains.

Run with only
{
# bugs/
include bugs/reftest.list
}

Then I tried to narrow that list down:
{
Whole file: leaks 6

start to 369882.xul: leaks 0
370353-1.html to end: leaks 3

370353-1.html to 405584-1.html: leaks 0
405952-1.html to end: leaks 0
}
There are more than 1,000 tests and I don't know how to "easily" find out which ones need to be run to trigger the leak :-/
Flags: wanted1.9.1?
(In reply to comment #0)
> 370353-1.html to end: leaks 3

I don't know what happened: this one is still 6.

> 405952-1.html to end: leaks 0

I had not saved the list file: this one is still 6.

The culprits are
{
== 411585-1.html 411585-1-ref.html
== 411585-2.html 411585-2-ref.html
fails == 411585-3.html 411585-3-ref.html # bug 426909
}
which leak 2 each.
(Maybe 1 from the test and 1 from the ref !?)
Blocks: 411585
Component: Layout → Printing: Output
QA Contact: layout → printing
Summary: 'bugs/reftest.list' leaks 6 nsDisplayBackground, when run as a whole → 3 'bugs/reftest.list > 411585-*.html' leak 2 nsDisplayBackground each
As a note, I have ran into issues while testing on fennec.  This bugs directory is so large I have had to split it up into 10 .list files and run each one standalone.  There isn't much I do other than some head & tail stuff to create smaller .list files, but if I can help out in any way, let me know.
(In reply to comment #2)
> I have had to split it up into 10 .list files

That is unrelated to this bug, but I guess the only solution would be to pre-process the list files to do that at build time.
(In reply to comment #2)
> and run each one standalone.

And build a list of all the lists, in order to run them individually instead of by includes as it is now.
as a reference for the fennec stuff I have entered a bug 471676 last year to find a method for running the tests in smaller chunks.
I'm seeing two constructor calls at the same address with no matching destructor.  Here's the part of the stack in common between those two calls.
Attached patch patchSplinter Review
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Attachment #356970 - Flags: superreview?(roc)
Attachment #356970 - Flags: review?(roc)
OS: Windows 2000 → All
Priority: -- → P3
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.2a1
Attachment #356970 - Flags: superreview?(roc)
Attachment #356970 - Flags: superreview+
Attachment #356970 - Flags: review?(roc)
Attachment #356970 - Flags: review+
Fixed: http://hg.mozilla.org/mozilla-central/rev/0eab2ed55fac
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 356970 [details] [diff] [review]
patch

Trivial fix to avoid skipping virtual destructors so that we fix the leak statistics.
Attachment #356970 - Flags: approval1.9.1?
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090117 Minefield/3.2a1pre] (home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/184eadf4e185 + bug 446300 patch)

V.Fixed
Status: RESOLVED → VERIFIED
Summary: 3 'bugs/reftest.list > 411585-*.html' leak 2 nsDisplayBackground each → leak 2 nsDisplayBackground when running each 411585-*.html reftest in bugs/reftest.list
Attachment #356970 - Flags: approval1.9.1? → approval1.9.1+
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1947fde473c5
Whiteboard: fixed1.9.1
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1b3
Keywords: fixed1.9.1
Whiteboard: fixed1.9.1
Flags: wanted1.9.1?
You need to log in before you can comment on or make changes to this bug.