http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1220978283.1220984059.13971.gz Linux comm-central dep unit test on 2008/09/09 09:38:03 http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1220991568.1220997331.17590.gz#err37 Linux comm-central dep unit test on 2008/09/09 13:19:28 TEST-UNEXPECTED-FAIL | runtests-leaks | leaked 8620 bytes during test execution (should have leaked no more than 0 bytes) http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1220981107.1220986059.19286.gz MacOSX 10.4 comm-central dep unit test on 2008/09/09 10:25:07 http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1220991568.1220996486.14976.gz#err61 MacOSX 10.4 comm-central dep unit test on 2008/09/09 13:19:28 TEST-UNEXPECTED-FAIL | runtests-leaks | leaked 8712 bytes during test execution (should have leaked no more than 0 bytes) http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1220980366.1220984306.14710.gz Win2k3 comm-central dep unit test on 2008/09/09 10:12:46 http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1220992491.1220996367.14764.gz#err56 Win2k3 comm-central dep unit test on 2008/09/09 13:34:51 *** End BrowserChrome Test Results *** TEST-UNEXPECTED-FAIL | runtests-leaks | leaked 8577 bytes during test execution (should have leaked no more than 0 bytes)

As long as one test of that suite is failing (bug 454513), I don't care about the leaks there, because it might just as well be a leak that's caused by the test failure itself.

(In reply to comment #1) Could be linked ... though the leak started "after" the test landed.

Confirming: bug 454513 is fixed ... and this leak is still there.

Judging from the size of the leak, this sounds very much like the known-to-happen bug 391318 issue. It'd probably interesting to see why we didn't leak up to a certain point and then started to trigger this one. In any case, not blocking an Alpha by a mere small leak.

Here are the c-c and m-c timeframes: http://hg.mozilla.org/comm-central/pushloghtml?startdate=2008-09-09+05%3A56%3A49&enddate=2008-09-09+11%3A31%3A49 http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-09+10%3A22%3A49&enddate=2008-09-09+13%3A16%3A29 (In reply to comment #4) > It'd probably interesting to see why we didn't leak up to a certain point and > then started to trigger this one. Exactly my point...

The wanted flag is mainly for (large) features that don't need to be fixed for a release but should be tracked as something we want to see in the final. This is no large feature, this is "just" another possibly real bug. Given how unsure we are what bug 391318 means in reality, i.e. apart from testing machines, and that this is probably "just" another case of this, it's surely no wanted feature - it might qualify for blocking if we find the underlying issue to be actually impacting users. The latter is very unsure at the moment, so I wouldn't even request blocking for this one, but we surely should investigate the underlying problem.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b1pre) Gecko/20080927115844 SeaMonkey/2.0a1pre] (home, optim default) (W2Ksp4) I built with { rev:16fab37cd726 m-c:4a1ad24a36bc } and verified that this leak is actually bug 391318. (In reply to comment #5) > (In reply to comment #4) > > It'd probably interesting to see why we didn't leak up to a certain point and > > then started to trigger this one. (As my build is "already" leaking with these revs,) I have no idea why the tinderboxes did not report it before they did :-( (I don't remember if I "used" to see this leak report locally or not: if not, it may have been because I tested with the workaround already applied :-|) *** Unless you want to try and test on the tinderbox themselves, (or someone else can reproduce) I suggest to resolve this bug as "fixed", now that the leak cause is confirmed (and the thresholds updated).

No, leak not fixed; but is caused By 391318 (per your last comment); so duping to that.

V.Duplicate, then.