Closed Bug 433132 Opened 17 years ago Closed 16 years ago

Running mochitest for bug 396024 still leaks

Categories

(Core :: Print Preview, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.9.1b1

People

(Reporter: ajschult784, Assigned: smaug)

References

()

Details

(Keywords: memory-leak, testcase)

Attachments

(1 file)

We leak 125K on the mochitest for bug 396024. Bug 408355 fixed the leaks introduced by bug 396024, but the other 125K remains.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080917032624 Minefield/3.1b1pre] (home, optim default) (W2Ksp4) The two lines which cause the ("unique") leak are function run2() { window.frames[0].location.reload(); and(/or) function run4() { var x = window.frames[0].frameElement.parentNode.removeChild(window.frames[0].frameElement); It would seem that when the content frame goes away, its "PrintPreview" is not released anymore !? ***** Note that |python runtests.py --test-path=layout/base/tests/test_bug396024.html --autorun --close-when-done --leak-threshold=0| needs a manual close for me :-/ But |python runtests.py --autorun --close-when-done| with only that file in the repertory works fine.
OS: Linux → All
The patch fixes the leak and I didn't see any leaks when testing printpreview and print (with and without bfcache, closing while printing etc.). The problem here is to make sure that NS_ADDREF_THIS has always a corresponding NS_RELEASE_THIS. The test for bug 396024 does some pretty evil things (like reloading an iframe while trying to show printpreview) and trying to track down such unusual cases is hard. So better to use nsCOMPtr: nsPrintEngine owns documentViewer and vice-versa. When printing is done or document viewer destroyed, the cycle is broken down.
Assignee: nobody → Olli.Pettay
Attachment #340439 - Flags: superreview?(roc)
Attachment #340439 - Flags: review?(roc)
Attachment #340439 - Flags: superreview?(roc)
Attachment #340439 - Flags: superreview+
Attachment #340439 - Flags: review?(roc)
Attachment #340439 - Flags: review+
Doesn't leak here anymore.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Did you check the patch in?
author Olli Pettay <Olli.Pettay@helsinki.fi> Fri Sep 26 12:51:42 2008 +0300 (at Fri Sep 26 12:51:42 2008 +0300) changeset 19768 13e6f70197a9 Bug 433132, Running mochitest for bug 396024 still leaks r+sr=roc
Okidoki.
Attachment #340439 - Attachment description: possible patch → possible patch [Checkin: Comment 6]
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080926173700 Minefield/3.1b1pre] (home, optim default) (W2Ksp4) V.Fixed ***** (In reply to comment #1) > Note that > |python runtests.py --test-path=layout/base/tests/test_bug396024.html --autorun > --close-when-done --leak-threshold=0| > needs a manual close for me :-/ I guess this is by design when running a test alone !?
Status: RESOLVED → VERIFIED
Component: Printing: Output → Print Preview
Flags: in-testsuite+
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1b1
No longer blocks: SmTestLeak
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: