Closed Bug 521104 Opened 15 years ago Closed 15 years ago

fastload leak with nsFastLoadFileUpdater, nsBinaryOutputStream, etc

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
normal

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).
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
No longer depends on: 389734
You need to log in before you can comment on or make changes to this bug.