Closed
Bug 521104
Opened 15 years ago
Closed 15 years ago
fastload leak with nsFastLoadFileUpdater, nsBinaryOutputStream, etc
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 389734
People
(Reporter: Dolske, Unassigned)
References
Details
There's been a solid string of orange on the "WINNT 5.2 mozilla-central test everythingelse" column today, although there have been a few recent green cycles. So, not sure if this is random or jsut clearing up.
Leak looks like:
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 3124 bytes during test execution
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 3 instances of nsBinaryOutputStream with size 16 bytes each (48 bytes total)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of nsBufferedInputStream with size 48 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of nsBufferedOutputStream with size 56 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 2 instances of nsBufferedStream with size 40 bytes each (80 bytes total)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 6 instances of nsFastLoadFileUpdater with size 240 bytes each (1440 bytes total)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 6 instances of nsFastLoadFileWriter with size 228 bytes each (1368 bytes total)
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of nsFileOutputStream with size 24 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of nsFileStream with size 20 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of nsStringBuffer with size 8 bytes
TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | leaked 1 instance of nsSystemPrincipal with size 32 bytes
Fastload hasn't been modified in the time before this started, but bug 389734 describes a very similar issue.
moz2-win32-slave43 did a successful run with changeset 50c9c5f6bb58, the next cycle was orange on moz2-win32-slave35 with changeset c21bf74e694b, and a few more oranges later slave43 was also orange with changeset 8edc006c5371.
Bug 518666 was what landed in the first changeset to go orange. It had a mistake, using Cu.import to load a non-existant JSM. This was fixed in a later changeset, http://hg.mozilla.org/mozilla-central/rev/bea32394861e
This seems really similar to the bug 389734 issue, but I'm not sure if jsm's go through fastload or if they're triggering the same issue.
Next action is to see if this is really clearing up, or if it's sporadic (and why).
Reporter | ||
Comment 1•15 years ago
|
||
This seems to have fixed itself shortly after the checked that corrected the .jsm name, so I'l just going to call this a dupe of 389734.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•