Closed Bug 411590 Opened 18 years ago Closed 11 years ago

Run leak test on Thunderbird tinderboxes

Categories

(Thunderbird :: Testing Infrastructure, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jminta, Unassigned)

Details

Certain large scale changes (e.g. STEEL, or switching the abook to mozstorage) could easily introduce new leaks into Thunderbird code. Currently, however, it's not at all easy to detect this. If the something like Firefox's RLk [1] test were running on the Thunderbird boxes, we would at least have a chance at catching a large segment of leaks. [1] http://build-graphs.mozilla.org/graph/query.cgi?testname=refcnt_leaks&units=bytes&tbox=fxdbug-linux-tbox.build.mozilla.org&autoscale=1&days=7&avg=1&showpoint=2008:01:09:14:58:21,
Indeed. One large scale change which is likely to add leaks would be bundling Lightning by default, which is likely not leak-free.
Is this still legit? and, do we have a meta bug this should be linked to, about improving our memory or test robustness story?
We do (refcount) leak tracking in xpcshell tests, but they don't show up as test failures (see bug 469523). Our tinderbox builds run mailbloat, which computes bloat (max mem) and leak number for refcounts, but these also don't show up as test failures, and the related graph server output appears to be unconnected. That said, the bloat tests are spectacularly useless since (IIRC) all they test is a compose window + message send. Conceivably, we could enable mozmill refcount leak tracking (which I can't find a bug for, surprisingly), although I think mozmill itself might be leaky. CC'ing Standard8.
The explicit leak tests were stopped ages ago - the preferred method now is as part of test suites.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.