The simple CC analyzer can be useful to find leaks, especially if the leak cycle contains a document. Install the addon (Bug 726346), load about:cc, 'Run cycle collector' and after getting the log click 'Find Documents'. Runtime leaks cause FF to use more memory and run CC slower.

I tried your add-on, but how long has 'Run cycle collector' to run before getting the log? When I run the cycle collection, I see only 'Processing. Please wait...'.

You need to run the very latest m-c builds. Bug 726346 is probably not yet in the latest Nightly. Running CC takes usually <1s with that addon and processing the log takes perhaps 1-2s. But if there lots of objects, processing may take a lot longer.

Doh, sorry, indeed I'm running the latest nightly not m-c build. I'll wait. Thanks. :)

Added [Snappy], because most of the leaks increase CC times dramatically.

Olli, can you please add some example scenarios so that QA has more info to go on.

So, use various functionality of Firefox, and run about:cc / cycle collector / find documents occasionally to check if some documents show up in the cycle collector graph. See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0

We should probably do similar testing for most common addons.

Also, about:cc shows some possibly leaked documents after cycle collector run, it is good to re-run cycle collector and find-documents to make sure that documents really stay there in the cycle collector's graph

(In reply to Olli Pettay [:smaug] from comment #6) > So, use various functionality of Firefox, and run about:cc / cycle collector > / find documents > occasionally to check if some documents show up in the cycle collector graph. > See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0 I spoke with Olli to clarify. Using various Firefox functions can include opening and closing menus, creating a bookmark, using a dev tool, opening bookmarks or history, etc. The point of this exercise is to test various areas of the browser to discover leaks.

ccing Anthony for QA help with the investigation.

(In reply to Olli Pettay [:smaug] from comment #6) > So, use various functionality of Firefox, and run about:cc / cycle collector > / find documents > occasionally to check if some documents show up in the cycle collector graph. > See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0 Is there any particular functionality I should focus my attention on? anything that is likely to showcase this bug more than others?

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #11) > (In reply to Olli Pettay [:smaug] from comment #6) > > So, use various functionality of Firefox, and run about:cc / cycle collector > > / find documents > > occasionally to check if some documents show up in the cycle collector graph. > > See https://bugzilla.mozilla.org/show_bug.cgi?id=728407#c0 > > Is there any particular functionality I should focus my attention on? > anything that is likely to showcase this bug more than others? I think the request is more of an exploratory one where we don't know the areas of the browser that may be leaky. Turning the request around, what areas do we know to be leaky that QA can avoid testing?

(In reply to Lawrence Mandel [:lmandel] from comment #12) > Turning the request around, what > areas do we know to be leaky that QA can avoid testing? Look at the bugs this bug depend on.

Anthony, as Olli noted in comment 13, the dependent bugs contain areas that are known to be leaky within the product. Can you create a test plan that broadly covers other areas of the product? We can use the results to drive further investigations.

(In reply to Lawrence Mandel [:lmandel] from comment #14) > Anthony, as Olli noted in comment 13, the dependent bugs contain areas that > are known to be leaky within the product. Can you create a test plan that > broadly covers other areas of the product? We can use the results to drive > further investigations. It's unrealistic to assume I can deliver on a request this broad. I've started an email thread with you, Lawrence, in this regard. I expect to work with you on a plan of action and then we will come back to this bug.

OK. Let's talk this out and come back with a reasonably scoped plan.

This has already been tagged (and then untagged) with MemShrink. We generally don't tag meta bugs in MemShrink.

Noming for k9o. I spoke with Olli, who said that preventing leaks is one of the best things that we can do to prevent unnecessary CC runs at this point.

Even more importantly, leaks make CC times bad.

While leaks are surely an important issue for k9o, I don't see any dependency bugs here that would affect the web apps runtime which has no Firefox chrome and no add-on support.

(In reply to Lawrence Mandel [:lmandel] from comment #16) > OK. Let's talk this out and come back with a reasonably scoped plan. Lawrence, I don't recall what was agreed upon here. Can you jog my memory and re-add qawanted to this bug if there's something needing our attention here? Thanks

Thanks for the ping Anthony. We documented the process we were to follow in https://wiki.mozilla.org/QA/Snappy/Chrome_Leak_Testing. I have an e-mail from Olli, Virgil and you from April with initial results that was never added to this bug. Here's the context that I have (newest first): Olli: Compiler or OS memory management shouldn't affect to this stuff at all. These leaks are something that browser UI causes. And since browser UI isn't the same on all the platforms, the results may be different. For example, on OSX we don't have print preview. Anthony: Here's the results for Tier 1 on Windows 7, Mac OSX 10.6, ad Ubuntu 11.10. Let me know if A) you need QA assistance investigating the two issues found and B) you want us to retest on other platforms/tiers. Hopefully this first run was useful to you. Thanks Virgil: Hi Anthony, Mihaela, Vlad and myself have performed chrome leak testing today on Firefox 14 Nightly and focused on tier 1 areas on Windows 7, Mac Os 10.6 and Ubuntu 11.10 32-bit. We have followed the steps specified in: https://wiki.mozilla.org/QA/Snappy/Chrome_Leak_Testing We have encountered two leaked document situations. Both of them being logged and listed already in the dependencies for bug 728407 : - https://bugzilla.mozilla.org/show_bug.cgi?id=728426 - https://bugzilla.mozilla.org/show_bug.cgi?id=728663 We've added the OSs in the test plan under tier 1 results. Please lets us know if there is anything else we can help with. Virgil

(In reply to Lawrence Mandel [:lmandel] from comment #22) > Thanks for the ping Anthony. We documented the process we were to follow in > https://wiki.mozilla.org/QA/Snappy/Chrome_Leak_Testing. Ah yes, thanks for the reminder Lawrence. Are there any next steps you want QA to take? Given this is now a P3 maybe it's now worth looking into at this time.

Like you said, this is now a lower priority. I don't think there's any need to do any additional testing at this time.

Leak hunting should happen continuously. I've found some leaks recently (Bug 839280 and Bug 833783). Since not too many use tools like about:cc we don't catch chrome leaks easily. (also, about:cc is rather awful addon. It does just the things I need.) So, I hope we could figure out what to do with bug 839489 and get leak detection more automatic.