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)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: Waldo, Unassigned)
References
Details
(Keywords: memory-leak, regression)
Attachments
(1 file)
33.59 KB,
text/plain
|
Details |
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•16 years ago
|
Keywords: regression
Reporter | ||
Comment 1•16 years ago
|
||
MOZ_CO_DATE="2008-03-18 12:00:00 PST" does not leak.
Reporter | ||
Comment 2•16 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.
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•16 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•16 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•16 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•16 years ago
|
||
MOZ_CO_DATE="2008-03-27 22:00:00 PDT" does not leak.
Reporter | ||
Comment 8•16 years ago
|
||
MOZ_CO_DATE="2008-03-28 15:00:00 PDT" leaks 321364 bytes. Getting there...
Reporter | ||
Comment 9•16 years ago
|
||
Reporter | ||
Comment 10•16 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•16 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•16 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.
Comment 13•16 years ago
|
||
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•16 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.
Comment 15•16 years ago
|
||
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•16 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
Closed: 16 years ago
Resolution: --- → WORKSFORME
Updated•16 years ago
|
Flags: wanted1.9.0.x+
Updated•16 years ago
|
Component: Testing → Mochitest
Flags: blocking1.9-
Product: Core → Testing
QA Contact: testing → mochitest
Version: Trunk → unspecified
Comment 17•14 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.
Description
•