Closed Bug 427313 Opened 16 years ago Closed 16 years ago

Running Mochitests on OS X leaks (didn't leak anything previously)

Categories

(Testing :: Mochitest, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: Waldo, Unassigned)

References

Details

(Keywords: memory-leak, regression)

Attachments

(1 file)

The last time I ran Mochitests on OS X, which was roughly two weeks or so ago, nothing leaked.  I just ran again today, and we leak 321436 bytes.  I'm going to try to do some delta debugging to get a regression window.
Keywords: regression
MOZ_CO_DATE="2008-03-18 12:00:00 PST" does not leak.
MOZ_CO_DATE="2008-03-26 12:00:00 PST" does not leak.

Actually getting this result requires that I copy {automation,runtests}.py from $objdir/_tests/testing/mochitest/ in a current trunk build to the equivalent location for the built source, because there seems to be a problem that popped up in that interval which kills things right around the time one of the jar: tests in the content directory runs.
Good this is before I landed the dom-level2-html stuff. Can't you remove all the mochitests that got checked in between those dates (http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=test&filetype=regexp&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-18+12%3A00%3A00&maxdate=2008-03-26+12%3A00%3A00&cvsroot=%2Fcvsroot) and verify that it is a code change rather than a testcase that got checked in.
MOZ_CO_DATE="2008-03-31 12:00:00 PST" leaks 321856 bytes.

I don't know whether the copying trick from the previous comment is necessary
or not, but I used it here too.  I have a vague memory of seeing funky console
logging that might have meant it was necessary, but I might not be remembering
correctly.

Regarding comment 3, I don't particularly care whether it was a new testcase or not.  If it wasn't, that's bad.  If it was, that leak should be fixed, and frankly I don't care much if that prevents a test from being checked in immediately, or if the test must be massaged to not leak until the leak can be fixed.

More binary building to go.  It's pretty insane that Bonsai claims (+11520/11531) Lines changed in this time interval; the tree's much more active of late than I ever remember it being in the past.
The dom2-html tests were not enabled on OS X in the previous checkout, to be clear, as verified by checking dom/tests/mochitest/Makefile.in.
MOZ_CO_DATE="2008-03-29 12:00:00 PDT" leaks 321364 bytes.

Note that the above is immediately before the dom2-html checkin, so not only are those test not enabled on OS X, but they're not even present.
MOZ_CO_DATE="2008-03-27 22:00:00 PDT" does not leak.
MOZ_CO_DATE="2008-03-28 15:00:00 PDT" leaks 321364 bytes.  Getting there...
Leaked document at address 417ad9a0.
 ... with URI "http://localhost:8888/tests/content/base/test/test_bug419527.xhtml".
Summary:
Leaked 0 out of 5717 DOM Windows
Leaked 1 out of 4761 documents
Leaked 0 out of 1834 docshells

...is the leak gauge output for the run from comment 8.  In fact, just running the Mochitests in content/base/test is enough to leak 278584 bytes; hopefully the remaining bytes are just greater entrainment due to running within a larger set of tests.
MOZ_CO_DATE="2008-03-28 05:00:00 PDT" does not leak on content/base/test.

I intentionally chose this checkout time because it was right before the checkin for bug 415192; the nature of the other commits in the range strongly suggests that checkin caused the leak, but I haven't yet verified -- doing so now.
Blocks: 415192
Flags: blocking1.9?
Bug 415192 is the culprit for at least part, probably all, of the leak, as verified by Mochitests in content/base/test before and after the checkin.
It's really really bad that peterv created that leak!  ;-)

However, we should clean this up in the first dot release.  Making cycle collector-type changes this late in the game is very risky.  wanted1.9.0.x+
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Flags: blocking1.9-
Hmm.  I just retested and "don't" leak on this; I once got a nsBaseAppshell/nsRunnable leak pair doing the content/base/test tests, but every other time I've tried doing that (while not moving the mouse at all, since this one run was run expecting the leak still existed) or running all the tests I no longer leak.

Individual leaks don't actually worry me, except when they happen to be large or plentiful.  What worries me is that it's so hard to ensure those leaks don't happen that the only way I see to make that happen is to get instantaneous feedback regarding new leaks so that the ability to detect unintentional leaks can never unknowingly be diminished.
Yeah, I'd started looking into this one but haven't been able to reproduce yet. It's definitely unexpected that we'd leak more with the fix for bug 415192.
This is pretty consistently gone now, and we're back to 0 leaks in a full Mochitest run on OS X.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Flags: wanted1.9.0.x+
Component: Testing → Mochitest
Flags: blocking1.9-
Product: Core → Testing
QA Contact: testing → mochitest
Version: Trunk → unspecified
Marking in-testsuite+ because leaks now turn mochitests orange.
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: