Add-ons are a major cause of memory leaks in Firefox. Add-on leaks are common and commonly severe. I've argued [1] that this is a problem that those of us who work on Firefox need to address -- it's not enough to blame add-on authors. We in MemShrink had a fair amount of success helping add-on authors fix leaks that we've found. But we've only found leaks in the add-ons that we run, which isn't representative of addon usage at large. I'd like to enlist QA's help in finding leaks in popular add-ons [0]. Basic leak checking is pretty simple: Install the add-on, then use the browser for a while, making use of the add-on's capabilities, whatever they are. Then follow Nick's zombie compartment instructions [2] to see if there are any zombie compartments. If you wanted to be more sophisticated, you could check for other kinds of leaks -- is Firefox's resident size within a "reasonable" range after browsing for a while? These kinds of non-zombie leaks are less common, however, and much more difficult to check for. Once STR for a zombie compartment is found, we can file a bug dependent on this one and contact the add-on author. MemShrink developers will be available to assist the author in tracking down the issue. [0] https://addons.mozilla.org/en-US/firefox/extensions/?sort=users [1] http://jlebar.com/2011/11/13/The_carrot%2C_the_stick%2C_and_the_wrench%3A_Add-on_leaks_are_everyone%27s_problem..html [2] http://blog.mozilla.com/nnethercote/2011/07/20/zombie-compartments-recognize-and-report-them-stop-the-screaming/

Anthony, is there a component for this kind of bug?

(In reply to Justin Lebar [:jlebar] from comment #1) > Anthony, is there a component for this kind of bug? Not AFAIK.

FYI, we are planning a testday this Friday, Dec 16th for "performance". I will see if we can make getting some data for this bug a priority for that testday.

This is definitely something I think we want to get the crowd's help on. I reviewed Nick's instructions and did a minor walkthrough myself. They're a little vague as to what a compartment is in about:memory?verbose and how you'd effectively notice one sticking around. Justin, any chance you might be willing to do a quick screencast we can show the community, maybe even stop in for a bit on Test Day to help align? It'd give us better results.

njn has been talking about writing a blog post specifically about testing for zombie compartments in add-ons, so perhaps he'd be able to help out here.

(In reply to Justin Lebar [:jlebar] from comment #5) > njn has been talking about writing a blog post specifically about testing > for zombie compartments in add-ons, so perhaps he'd be able to help out here. I haven't done that yet, but bug 695471 comment 2 is partly there and hopefully enough to get you going for the test day.

Nick, I'm not sure that comment adds a lot of info over and above the blog post. It does mention to exercise the add-on, which is good. The challenge with your explanation as it stands is that while it's easy enough to see a line that says compartment (url), it's not nearly as straightforward to match a compartment with an add-on. For example, I currently have four add-ons installed. However, there are only three non-page compartments, two of which are marked System Principal, and the other moz-nullprincipal. Since this effort is particularly about testing add-ons, we'll need further instructions packaged for the crowd as to actually understand what compartment goes with the add-on and how to recognize when it disappears It would help if we had step-by-step instructions on doing the safe mode isolation as well. Right now it's just a footnote since it was framed as unimportant to your blog post (re: "depends on popularity"). It's possible I can help on the safe mode instructions, but I don't know how to do the correlation between compartments and add-ons. That'll likely have to come from you folks.

You don't correlate between compartments add-ons. If a compartment for *any page* is alive when that page's tab has been closed and |minimize memory usage| has been clicked, then the compartment is a zombie. So to be concrete, to test for an add-on leak, you do: > Install the add-on [i.e, just *one* add-on], then use the browser for a while, making > use of the add-on's capabilities, whatever they are. Then follow Nick's zombie compartment > instructions [2] to see if there are any zombie compartments. If there are any zombie compartments, for any page, then either Firefox or the add-on has a bug.

Note that there's already a screencast on looking for zombie compartments. Do you have enough information at this point to write something up for the testday, Geo? I'm happy to proofread.

Justin, thanks for the clarification re: correlating add-ons leaks to compartments. Sounds like we're probably mostways there. I didn't see the screencast, though. Can you point me at it?

Justin, awesome, thanks for the link. I'll check it out.

I just wrote https://developer.mozilla.org/en/Zombie_Compartments. It's aimed at being a very clear guide to finding zombie compartments, and includes instructions specifically aimed at finding leaks in add-ons. Please let me know if anything is unclear, or feel free to modify it yourself. W.r.t. the test day, it would be great to test something like the top 10 add-ons on AMO, and the top 5 in each category. (Or more! More is better :) Some of them (e.g. GreaseMonkey, Stylish) are so flexible they're hard to test, but most of them shouldn't be too hard.

I think the focus of this upcoming test day is likely to be looking for GC pauses since it's a little easier to point new contributors at. However, given that these new instructions are pretty clear (and thanks!) I'll see if we can suggest that more advanced contributors help out in looking for leaks. If we don't get sufficient coverage this Test Day, we can do a followup effort.

The test day has come and gone. I saw maybe one or two bug reports as a result, but nothing substantial. Did the top 10 get tested? Can we close this bug? It's not clear to me what are the criteria for closing this bug.

Nick, the test day had low attendance, and I don't think we got that level of coverage. I plan on rerunning it in January.

Geo, is there a test day scheduled for January?

(In reply to Nicholas Nethercote [:njn] from comment #17) > Geo, is there a test day scheduled for January? Geo, you can take Friday Feb 3rd if you want.

Tentatively, sure. Let's talk tomorrow.

I just created bug 730737 which is much the same as this but more ambitious: it aims to test the 100 most popular add-ons instead of 10, and to draw that top 100 from all add-ons, not just AMO. I chose not to morph this bug because it has a bunch of discussion that might be confusing to newcomers who are interested in helping with the testing.