579577 - Use dynamic analysis to automatically diagnose cycle collector leaks

Status: RESOLVED WONTFIX

(Testing :: General, defect)

Description

[Andreas Gal :gal]

We have a set of tools and a tutorial that explains how to use them:

http://www.mozilla.org/performance/leak-tutorial.html

The tutorial is step by step and hence should be easy to automate.

Every time the tinderbox detects a leak, we should run the analysis and provide a brief output:

hey, you leaked "this" "here".

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Doesn't Valgrind output provide a useful analysis?

Comment 2

[Jesse Ruderman]

See https://wiki.mozilla.org/Performance:Leak_Tools for an overview of our leak tools.  This page gives context to the four leak tools that have been mentioned in this bug report (trace-refcnt, trace-refcnt with logging for the balancer, cycle collector debugging, and Valgrind).

It would be great to automate more of the refcnt balancer for fully reproducible bugs.  But the required logging slows Firefox down a lot, so we can't use it for "all our tests all the time" as a protection against inexplicable orange.  (The same goes for Valgrind.)

If we could somehow integrate trace-refcnt-style debugging with record-and-replay, we might be able to pull it off without a huge perf hit ;)

Comment 3

[Andreas Gal :gal]

These are different kinds of leaks. These are cycles in the graph that survive past shutdown. A keeps B alive keeps C alive keeps A alive. The cycle collector is supposed to collect these, but sometimes fails to. We have some tools do diagnose such cycles. This bug is about seeing whether we could automate some of that analysis.

Comment 4

[Jesse Ruderman]

Is there a subset of DEBUG_CC that we could include in automated tests, that would be fast and low on false positives?

Or could we use static analysis instead (bug 423032?) to find these kinds of bugs?

Comment 5

[Nicholas Nethercote [inactive]]

Should this be a dup of bug 423032?

Comment 6

[Andrew McCreight [:mccr8]]

This is talking about dynamic analysis, while 423032 is talking about static analysis.  There are enough weird special cases in the cycle collection code that I've seen just in the past week that I don't think we'd want to go with a purely static approach.

There is actually already some kind of console spew about what is holding on to leaks, but I don't know if anybody actually uses it.  And it is only the beginning of finding a leak.

Comment 7

[Nicholas Nethercote [inactive]]

Gal, we talked about this in the MemShrink meeting, the consensus seemed to be that it's hard to automate the tools that you're talking about.  (Automating dynamic tools like Valgrind is easier, but that (a) is covered by existing bug 631811, and (b) only detects shut-down leaks.)

So unless you can be more specific, it's unlikely this bug will go anywhere.

Comment 8

[Julian Seward [:jseward]]

(In reply to comment #7)
 > (Automating dynamic tools like Valgrind is easier, but that (a) is covered
> by existing bug 631811, and (b) only detects shut-down leaks.)

FTR, there's an as-yet unlanded patch at 
https://bugs.kde.org/show_bug.cgi?id=214909#c105
which provides delta leak checking for Memcheck -- it can produce
a leak report showing just new stuff leaked between two program
points.  Maybe useful?  I plan to get it into V 3.7.0.

Comment 9

[Geoff Brown [:gbrown]]

Mass closing bugs with no activity in 2+ years. If this bug is important to you, please re-open.