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

RESOLVED WORKSFORME

Status

Testing
Mochitest
RESOLVED WORKSFORME
10 years ago
9 years ago

People

(Reporter: Waldo, Unassigned)

Tracking

({memory-leak, regression})

unspecified
x86
Mac OS X
memory-leak, regression
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.

Updated

10 years ago
Keywords: regression
(Reporter)

Comment 1

10 years ago
MOZ_CO_DATE="2008-03-18 12:00:00 PST" does not leak.
(Reporter)

Comment 2

10 years ago
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.

Comment 3

10 years ago
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.
(Reporter)

Comment 4

10 years ago
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.
(Reporter)

Comment 5

10 years ago
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.
(Reporter)

Comment 6

10 years ago
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.
(Reporter)

Comment 7

10 years ago
MOZ_CO_DATE="2008-03-27 22:00:00 PDT" does not leak.
(Reporter)

Comment 8

10 years ago
MOZ_CO_DATE="2008-03-28 15:00:00 PDT" leaks 321364 bytes.  Getting there...
(Reporter)

Comment 9

10 years ago
Created attachment 313954 [details]
Leaks from comment 8 Mochitest run
(Reporter)

Comment 10

10 years ago
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.
(Reporter)

Comment 11

10 years ago
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?
(Reporter)

Comment 12

10 years ago
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-
(Reporter)

Comment 14

10 years ago
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.
(Reporter)

Comment 16

10 years ago
This is pretty consistently gone now, and we're back to 0 leaks in a full Mochitest run on OS X.
Status: NEW → RESOLVED
Last Resolved: 10 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

Comment 17

9 years ago
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.