Closed Bug 1217681 Opened 11 years ago Closed 10 years ago

Intermittent TEST-UNEXPECTED-FAIL | leakcheck | tab process: leaked too many nsPerformanceStatsService (expected 0, got 1), | tab process: leaked too many nsStringBuffer (expected 0, got 1)

Categories

(Toolkit :: Performance Monitoring, defect)

Product:
Toolkit
Component:
Performance Monitoring
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox44 --- affected

People

(Reporter: philor, Assigned: Yoric)

References

Details

(Keywords: intermittent-failure, memory-leak)

Keywords: mlk
Looks like a dupe of bug 1217218, right?
Dependency that I'm guessing you mean will be fixed-by, but it's not a dupe, since that's about ASan's method of detecting leaks and this is about our homemade method (one way of "fixing" ASan leaks is to say "I meant to do that" and just suppress the report, which won't work for this), and that's suggested only for ASan leaks while this will (I presume, eventually, when treeherder decides to regenerate its bug cache) be suggested for the leak in non-ASan tests.
Depends on: 1217218
This is a new method of detecting leaks that I added (bug 1215148) that is different from ASan, but it is almost certainly the same underlying issue. philor, just so you know, there is actually a way to suppress these leaks, too: http://mxr.mozilla.org/mozilla-central/source/testing/mozbase/mozleak/mozleak/leaklog.py#23 In this case, of course, the leak needs to actually be fixed.
Summary: Intermittent leakcheck | tab process: leaked too many nsPerformanceStatsService (expected 0, got 1), | tab process: leaked too many nsStringBuffer (expected 0, got 1) → Intermittent TEST-UNEXPECTED-FAIL | leakcheck | tab process: leaked too many nsPerformanceStatsService (expected 0, got 1), | tab process: leaked too many nsStringBuffer (expected 0, got 1)
So bug 1217218 seems to have considerably decreased the number of leaks, but not entirely eliminated it. How does this leak detector work, exactly? Could it possibly be executed before we have finished shutting down the performance stats service?
Flags: needinfo?(continuation)
(In reply to David Rajchenbach-Teller [:Yoric] (use "needinfo") from comment #16) > So bug 1217218 seems to have considerably decreased the number of leaks, but > not entirely eliminated it. Yesterday's failures were all on try, so I think the leak is fixed.
Flags: needinfo?(continuation)
Assignee: nobody → dteller
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
So, apparently, not all failures are on try. So, back to my original question: How does this leak detector work, exactly? Could it possibly be executed before we have finished shutting down the performance stats service?
Flags: needinfo?(continuation)
(In reply to David Rajchenbach-Teller [:Yoric] (use "needinfo") from comment #19) > So, apparently, not all failures are on try. So, back to my original > question: How does this leak detector work, exactly? Could it possibly be > executed before we have finished shutting down the performance stats service? There haven't been any failures outside of try since November 2. https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1217681
Flags: needinfo?(continuation)
Oh, I hadn't realized that comment 18 was a report for the entire week.
You need to log in before you can comment on or make changes to this bug.