Lots of activity this week.
Leaky add-ons
I created a new devmo wiki page documenting common causes of memory leaks in add-ons. I based this on a lovely selection of examples provided by Nils Maier. Unfortunately, I know almost nothing about writing add-ons and so I’m not happy with the current state of the documentation. I’ve taken it as far as I can, but it very likely has errors, leaves out important cases, conflates distinct concepts, and generally is not as good as it should be. This documentation is really important — we have good tools for identifying when add-on leaks occur but we don’t yet have good tools for identifying their causes. Until we have those tools, documentation is the only way we can help add-on authors fix leaks. If someone who knows more about add-ons is willing to help please contact me!
Alexandre Poirot fixed a leak in the Add-on SDK that was causing zombie compartments when certain add-ons were disabled. This also fixed bug 725603 and probably fixes some zombie compartments reported in some other add-ons (e.g. MemChaser).
Jan fixed several leaks in the Galaxytoolbar add-on. The new version is 2.6.12.
A small number of add-ons have been found that disable Firefox’s XUL cache. This is a recipe for disastrous performance, and so Matt Basta updated the AMO add-on validator to detect this.
Tools
I landed support for a new page called about:compartments. The exposure of zombie compartments in about:memory has become an extremely powerful leak detection tool. But using about:memory to find zombies is non-trivial — there are multiple steps and ways to get it wrong. The motivation for about:compartments is to make the detection of zombie compartments as simple as possible. Here’s a screenshot:
Some things to note:
- It only shows compartments, and all of them.
- User compartments from web content (usually the interesting ones) are listed separately from system compartments.
- The garbage and cycle collectors are automatically run when the page is loaded, ensuring that dead compartments aren’t listed.
- The “More verbose” link at the bottom just causes the truncated URLs to be shown in full.
- about:compartments shares a lot of code with about:memory.
- I updated the documentation on zombie compartments accordingly.
Olli Pettay created about:cc, an add-on that can detect various kinds of document leaks relating to cycle collection. Olli has already found several leaks with this tool. Jan Honza Odvarko has written about:ccdump, a similar but prettier add-on. I’m not certain but I think Olli and Jan are now co-ordinating their efforts.
I mentioned Mozilla QA’s MemChaser add-on a few weeks ago. It lets you track memory usage and GC/CC activity easily via the add-on bar, and also allows logging of memory-related activities. It’s now available on AMO, which guarantees you’ll receive updates as they’re released.
Jesse Ruderman tweaked his DOM fuzzer and found several new small leaks relating to nsITimers. Jesse also modified about:memory so that it produces assertions that his fuzzer will catch. This means that his fuzzer will detect if any memory reporters produce bogus values.
Miscellaneous
Kyle Huey fixed a zombie compartment that occurred when searching within pages with onclick handlers, which is a pretty common operation.
Jeff Muizelaar fixed a huge Mac-only leak relating to text rendering. This was a recent regression that isn’t present in any released version of Firefox.
Josh Aas fixed a bug in cookie clearing — prior to Josh’s fix, if you cleared all cookies, Firefox would launch an instance of the plugin-container process for every plug-in installed, which could cause freezes and memory spikes.
Andrew Quartey updated the WebGL memory reporters to the new style.
Bug counts
This week’s bug counts:
- P1: 28 (-1/+3)
- P2: 134 (-6/+9)
- P3: 79 (-8/+11)
- Unprioritized: 2 (-1/+2)
Lots of movement there: plenty of bugs fixed, but even more new ones. Roughly 20 of the new ones fell into the following three categories.
- Zombie compartments found in AMO add-ons by Kris Maglione and Andreas Wagner.
- Leaks found by Olli Pettay’s new about:cc tool, mentioned above.
- Leaks found by Jesse Ruderman’s tweaked DOM fuzzer, mentioned above.
This is a good thing! It shows that new policies and tools are exposing existing problems. I expect this higher level of new bug filing will continue for a couple of weeks.
14 replies on “MemShrink progress, week 36”
In your documentation https://developer.mozilla.org/en/Extensions/Common_causes_of_memory_leaks_in_extensions you have used the unload() function in the section meant for removing event listener for bootstrapped add-ons.
It would be better to provide the unload function also, as user would think that it is a predefined function. Or do not use it at all ?
For the record, I am editing and providing a link to the gist for the unload function. Hope it helps.
Thanks!
I had a thought – valuable or not I do not know. Would it be helpful to add a link at the bottom of about:memory to about:compartments?
This might be a good place for other memory related ‘about:’s should they arrive. Pages such as about:compartments is memory related but doesn’t fall in the scope of about:memory’s features. It could be a help to someone trying to troubleshoot/explore memory stuff.
Is there any reason why the crowdsourcing (for want of a better term) approach cannot be taken to identifying add-on leaks? I remember reading somewhere about references to the window object being a big source of leaks. Is it as simple as reading through the source code of an add-on and looking for such references then seeing if they get unreferenced? It may sound very laborious but I’d enjoy doing that if it helps to make Firefox better. Having a web developer background, add-ons are more my scene in terms of any coding I could do to help the project. More so than C++ and so on, for example.
The hard part is knowing which add-ons are worth looking at and finding their code. AMO add-ons are easy in this respect; non-AMO add-ons are much harder.
Possibly a more useful crowdsourcing technique is to just test add-ons to see if they create zombie compartments when exercising their basic functionality. That’s faster and easier than looking through the source code. If you want to do this you could just start with the most popular ones on AMO — even though each AMO add-ons will eventually be tested for leaks when new versions are reviewed, it wouldn’t hurt to have someone look at them sooner. If you find any leaks, please file bugs!
Actually, see https://bugzilla.mozilla.org/show_bug.cgi?id=730737, which is about crowdsourcing the testing of the top 100 add-ons, including non-AMO ones.
Honza’s addon is now
https://addons.mozilla.org/en-US/firefox/addon/cycle-collector-analyzer/
(Waiting for review still)
Now reviewed. It makes it super easy to find zombie documents. I have a small cluster that seems to involve a posterous page and two twitter widgets, but after walking the graph a bit I’m not clueful enough to diagnose it.
What’re the differences between the cycle and garbage collectors?
The garbage collector is a standard one, and just works for JavaScript data. But Firefox allows references between JavaScript objects and C++ objects, and the cycle collector is needed to break cycles between JS-land and C++-land.
I was just wondering if my laptop screen is 1280×720, and if a website has a lot of big JPG files (4256*2832 for each, and 20 of them, to be exact, as in this page: http://www.newsmth.net/bbstcon.php?board=Picture&gid=791494&start=791494&pno=1, which eats around 1GB memory), does Firefox decode each JPG into raw data (e.g., YUYV) and hold 4256*2832*2 bytes per image in memory and still shrinks the images to fit the LCD display?
I think it would be much better/clever to store in memory the raw data of 20 scaled-down images (e.g., no more than 1280×720 in my case), and if the user really wants to see the full-size version, firefox can decode, upon request, THAT image again.
I was wondering how firefox handles big images, e.g., in the following webpage:
http://www.newsmth.net/bbstcon.php?board=Picture&gid=791494&start=791494&pno=1
which eats up ~1GB memory.
There are 20 big images, each one a 4256*2832 JPG = 4256*2832*2 YUYV = 24,105,984 bytes, and some smaller JPGs as well.
Does it hold 24,105,984 * 20 bytes of uncompressed data in memory, and display a scaled-down version of each image (in my case, 1280×720 LCD screen resolution or smaller)? or does it hold the scaled-down version of each images in memory? For many users like me, the scaled-down version is good enough, and if we ever want to check out the full-size version of an image, we can tell firefox to do so, that’s the cue to start decoding THAT image again.
about:compartments and about:ccdump seem to be what was needed for anyone to easily find and report zombie compartments !
I think I found a scenario creating a zombie compartment : installing any “no restart” extension from AMO will create a zombie compartment for the AMO page (https://addons.mozilla.org/en-US/firefox/)
I just need to confirm with a clean profile before submitting a bug and hope I understood correctly how to interpret about:compartments and about:ccdump
This is really great work. Its good to see that problems are being addressed and solved very well. There should be an active system that dynamically updates that black lists addons which are known to have problems and don’t run good.