Add-ons
The big news this week was the release of Firefox 15, which prevents most add-on memory leaks. As a consequence, we were able to close open bug reports for several add-ons that no longer leak: Firebug (yay!), Enter Selects, LinkResolve, We-Care Reminder, Restartless Restart + SmartSearch (the leak happened only when both were installed).
Although Firefox 15 prevents most zombie compartment leaks, some remain.
- Scriptish still leaks. Scriptish is a GreaseMonkey fork. Fortunately it has many fewer users than GreaseMonkey.
- Speed Dial creates a zombie compartment when adding a new page to the speed dial. This was only just reported, so we don’t yet know if it pre-dated Firefox 15 or not.
I haven’t heard much feedback about the release from actual users. This is probably a good thing, as users are much more likely to notice and report problems than improvements. One thing that has cropped up is that a small number of add-ons have had their functionality adversely affected by the change, i.e. they were accessing compartments for a page after the page has been closed.
- This caused certain GreaseMonkey scripts to leak badly. This has now been fixed.
- AutoPager’s main functionality is now broken. On the upside, it no longer leaks. AutoPager’s author hasn’t been responsive for the past five months, unfortunately.
- TabMix Plus is popping up some error windows that it shouldn’t.
- Two users with many add-ons installed have reported increased memory consumption. The add-on(s) responsible haven’t been identified yet.
If you have any additional add-ons that you think have been adversely affected by Firefox 15, open the error console and use the “filter” search box in the top right-hand corner to look for a message that says “TypeError: can’t access dead object” — that’s the message that indicates an add-on is trying to access memory via a reference that Firefox 15 has pre-emptively cut. Please report any problems in Bugzilla and put “[MemShrink]” in the whiteboard field.
On a related note, the discussion of Firefox 15’s release on various tech sites prompted me to debunk the common misconception that Mozilla claims “this is the release that fixes the memory leaks” on every release.
Other stuff
Andrew McCreight fixed a problem involving the cycle collector that could cause occasional leaks.
Brian Nicholson roughly halved the amount of memory used in Firefox Mobile’s page readability check. (This wasn’t actually marked as a MemShrink bug; I just chanced upon it today when looking at TBPL.)
Nick Cameron fixed a small, obscure leak.
Google Reader
For quite a while now we’ve had various people say that Google Reader creates lots of windows and/or compartments and causes Firefox’s memory consumption to gradually increase when it’s open for a long time. This may only happen if you are signed into a Google+ account. It feels like it’s a problem with Google Reader itself rather than Firefox, and a Google Reader engineer is CC’d on the bug report, but no progress has been made, and the reported symptoms are on the vague side.
If you have experienced this, we’d love to hear your feedback in the bug report. In particular, as always, reliable steps to reproduce would make a big difference.
Bug Counts
Here are the current bug counts.
- P1: 22 (-3/+1)
- P2: 90 (-2/+3)
- P3: 96 (-9/+7)
- Unprioritized: 2 (-2/+2)
Forward progress! Good to see.
35 replies on “MemShrink progress, week 63–64”
Hi,
I am currently using FF15 with following addons (updated). I usually see memory usage of my FF spirals upto 2GB in 2+hour. Mostly I kill FF (as cant really close it). I am not sure if there is any leak, but some addon might be eating too much. How to I find problematic addon and report ?
Adblock Plus
All-In-One Sidebar
Auto Shutdown NG
Download Helper
Fox Clocks
Grease Monkey (hardly any script there)
Profile Switcher
Save Image in Folder
Save-To-Read
Save Password Editor
Scrapbook
Session Manager
Show Parent Folder
Test Pilot
Great to see these improvements in the wild.
For an add-on like Autopage, if the creator is not responding, that add-on should be marked as not compatible and should be depreciated.
I know that this sentiment is rather negative, but the greater good of Firefox should be a priority first. If an Author no longer support an add-on, then why should Mozilla / Firefox support the add-on.
Google Reader isn’t the problem really, it is Google’s +1 button on posts, the embed leaks on most sites, Reader just makes it obvious because it opens a new one each time you view a post.
You mean this?
To NNethercore: if these buttons are more than 90% similar, shouldn’t FF create a template from the Google+, and only insert/keep the differences at each place, with a refer to the template for the rest?
@Jigar Shah : I guess you have to disable half of your add-ons and test to see if it still happens. And when you spotted the half that still triggers high memory consumption, disable more add-ons and so on.
Firefox 15 doesn’t have the “Filter” textbox in the Error Console; that didn’t land until Firefox 16. (As I recall there’s also talk of turning it off because it looks terrible on the Mac.)
I think LastPass extension is still leaking to heap-unclassified and it’s very similar to “Restartless Restart + SmartSearch” leak. I tested like this:
1. Install latest Nightlly build.
2. Create new profile.
3. Install “LastPass” (https://addons.mozilla.org/en-US/firefox/addon/lastpass-password-manager).
4. Install “Restartless Restart 8” (https://addons.mozilla.org/en-US/firefox/addon/restartless-restart).
5. Restart Firefox.
6. Login to LastPass account using extension.
7. Open a new tab with about:memory. Heap-unclasiffied is ~ 7-8Mb.
8. Open a new tab with http://www.gsmarena.com/apple_ipad_3-review-739.php
9. Click on the first iPad image in the review – a popup opens.
10. Close the popup.
11. Repeat 9-10 steps 20 times.
12. Go to about:memory tab and click “Minimize memory usage” button.
13. Check line with heap-unclassified – it is ~75Mb and never goes down.
This doesn’t happen (heap-unclassified stays at about the same level with just minimal increase) while user IS NOT logged-in to LastPass account, even if LastPass extention is installed and enabled in Firefox.
I reported this to LastPass support team a while ago and they could reproduce the problem eventually.
You can get similar result with LastPass and some other extensions installed, e.g. TabGroups Menu.
Thanks for the report. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=788906 for this.
Hello,
I read almost every posts here, Firefox is better and better I can tell.
I’m surprised people having huge memory consumption, well I guess you have many tabs open -like me-
What make me think again is nobody talks about memory related addons which decrease memory consumption / 10 at their best. I use them all the time I’m always running 50 to 60 tabs ; even more. 1/2 of them may be ghost windows but still my memory consumption can decrease up to 200Mb.
WHY ? Because I’m using addons to optimize and search and destroy memory leaks. I guess.
For those people having issues with memory ; you should try some Firefox Addons that kill them.
Which add-ons are you using? I’ve heard of these kinds of add-ons, but I’m extremely sceptical about them. Having worked on memory consumption for over a year I don’t believe there are easy wins of this sort to be found, but I’d also love to be proven wrong.
You can remove the Google+ button with wallflower: https://addons.mozilla.org/en-US/firefox/addon/wallflower-1/?src=ss
Ah, it seems i have an addon that make this “TypeError: can’t access dead object” : it is grab and drag.
I’ll try to make it to bugzilla.
I’m seeing exactly the opposite of what Mozilla claims for Firefox 15: the browser is eating up impressive amounts of memory and I don’t even use any add-ons. I only have the Silverlight, Flash and Java plugins installed. MacOS 10.6.8. Any idea why?
No add-ons… interesting. What do you mean by “impressive”, and how does it compare to Firefox 14? Can you cut and paste the contents of about:memory?verbose and about:support and sent them to me via email? Thanks.
I guess “impressive” was a poor choice of a word. I meant Firefox 15 is worse for me from a memory usage point of view. While Firefox 14 used around 700MB of memory after being opened for a few days, Firefox 15 is using 1GB after less than an hour for the same tabs. I will email you the info you requested. Thanks.
Just installed Firefox 15.0.1 and the memory problems I experienced with Firefox 15 seem to be gone. Around 500MB for the same tabs for which Frefox 15.0.1 needed close to 1GB.
That’s odd. As far as I know the only change in 15.0.1 was a change to fix a problem with private browsing mode. Do you use private browsing mode?
No private browsing mode. No add-ons.
I use two extensions that give the TypeError: can’t access dead object message in error console, CoolPreviews 3.7 and GoogleEnhancer 1.93. I haven’t noticed any performance issues in Firefox 15 or earlier versions and the extensions seem to work normally. Are the extensions safe to use or should I report the error to their developers?
If they seem to be work I’d continue using them, but reporting the error to the developers is also a good idea.
I’d like to report my problem to the author of Grab and Drag but I can’t find any mean to join him (https://addons.mozilla.org/fr/firefox/addon/grab-and-drag/).
Would there be another way ?
There is an email address listed on that page — look for “Courriel d’assistance” (or “Support E-mail” on the English page).
I love Firefox and the latest version is running really well. Seems slightly faster than the competition which is great.
Had firefox running for several days and something leaked really bad. This is the verbose about:memory with all tabs closed….
http://pastebin.com/WCJ4SfSL
Ugh. Are you able to reproduce the problem? Without steps to reproduce we’re unlikely to be able to do anything.
Hello,
I’d like to preface what follows by saying that I note FF15 uses significantly less memory than FF14 and previous. This is very nice. With that said, here is something I was hoping would get addressed but seemingly didn’t completely go way, and some limited attempts at debugging.
1. Observation: playing flash videos (e.g. Youtube, both directly and embedded in other pages) leads to higher memory usage. Several updates of the flash player didn’t fix this. FF becomes very slow when playing videos, videos skip, even the stream buffering of videos is slow, etc.
2. Observation: video playback is not as bad if I let the video download entirely first. Disk activity quiets down somewhat, and then performance is less bad. These led to:
3. Observation: video playback performance is worse when FF’s web data cache is full. It’s configured to the default, 1GB.
So this led to me to suspect probably there are two things going on. One is that the swap space used by Firefox is still too high, as evidenced by what happens when I shut down FF and swap space use goes down by 1gb. Two, FF is trying to clear up enough space in the data cache and it’s running into trouble.
From past experience with the data cache I know deleting it completely could require over 1 hour of disk i/o. In part this was because files would be deleted in random order (from the point of view of the file system). Eventually this was fixed so files were deleted in order plus deletion became some sort of offline process where the whole cache is first moved and then deleted in order, and this sped up managing the cache. However, it is still the case that the file cache tends to hold a huge number of mostly small files.
The last time I deleted the cache when it reached 1gb, I also ran fdupes on the whole cache directory tree. I had observed before many tiny files (~500 bytes) that were mostly the same by eye inspection, and I suspected perhaps they were wholly duplicate files. This time, fdupes produced output showing hundreds of duplicated files. So, question 1a: could it be possible to MD5 all files going into the file cache, and only add new files to the file cache when the MD5 hash is different (or, if the MD5 hash is equal, then a subsequent hash breaks the tie or the file contents are compared)? The idea behind this is “no duplicate files in the cache” -> “better cache utilization” -> “less disk i/o” -> “more responsive FF”. Question 1b: when needing to make up enough space in the file cache, is it possible that the operation could result in time wasting when needing to free up (say) 30mb and the deletion proceeds by freeing ~500 bytes at a time? If so, what could be done to address the problem? I ask because, in general terms, heavy disk i/o might be confused with swap file thrashing and the implication that FF is using too much memory to begin with etc.
Question 2: why is it that the swap space use grows seemingly in roughly direct proportion to the amount of videos streamed with the flash player? I have the following add-ons installed and up to date: Adblock Plus, Chatzilla (I don’t currently use it), Divx Plus Web Player HTML5 , DownloadHelper, Google/Yandex search link fix, Greasemonkey, Remove Google Tracking. What could I do that is not immediately obvious to determine whether the flash player is behind what I see in the OS X Activity Monitor, i.e. very large amounts of swap space freed when closing Firefox which tends to happen only after streaming videos from e.g. Youtube? Is there somewhere I could determine what is all that swap space being used for?
I’d be happy to spend some time to help figuring this stuff out.
Andres.
Your proposed caching changes and video playback problems sound more like a snappy issue than a memshrink one. Taras’s blog would probably be a better destination for them.
https://blog.mozilla.org/tglek/
Dan, ok, so I cross posted the relevant section at the Snappy blog.
If you have pointers on what I could do to figure out whether the suspicion about the flash player pans out, I’d be glad to help provide the relevant bits of information.
After being on Firefox 15 for a few days, I’m pleased to report that its memory use has been the best yet. (My issues with 14 may have stemmed from a corrupt places.sqlite file; it’s really hard to say for sure.) With Firebug and Greasemonkey finally in line, the browser seems to be able to take a lot more of a workout and the memory use hasn’t been growing steadily over time. There does seem to be some growth, but that’s to be expected and the critical difference is that I’m not seeing the zombies I was before.
Sadly the jump from 13 to 15 did represent the worst case of updateitis I’ve had to go through for a while. 14 broke the urlbar in all kinds of ludicrous ways on the UI team’s whim, and I needed two add-ons to fix that. I know it was a design decision, not an actual bug, but I’m still treating it as one because it was unnecessary and ill-considered and at the very least they should have given users some about:config options. Gah.
At least MemShrink is on the ball. Keep up the good work.
My experience with 15.0 and 15.0.1 so far has been that most compartment leaks have been stopped.
On the first day of using 15.0, about:memory contained red messages regarding problems with the numbers from memory reporters. I’ve only seen this on that one occaision and don’t know how to reproduce the issue.
The issue I have seen is with compartments being leaked by xsl transformed documents. A reduced example of this with all add-ons disabled …
1) Initially about:compartments?verbose reports no user compartments
2) When the main.xml file is loaded in a tab, about:compartments reports the user compartments…
file:///C:/DirPath/HTML2/main.xml
file:///C:/DirPath/HTML2/main.xml, file:///C:/DirPath/HTML2/object1.html [4]
I.e. the main.xml document and 4 compartments for 2 html objects displayed by the transformed doc … possibly outer and inner compartments? for each of the 2 objects … the transformed doc has a body containing 2 divs and each div contains 1 object, the same simple html doc is used for both objects
3) After deleting the main.xml tab, about:compartments reports the user compartments…
file:///C:/DirPath/HTML2/main.xml, file:///C:/DirPath/HTML2/object1.html [2]
I.e. 2 compartments for the loaded objects have not been cleaned up. The main.xml compartment and 2 of the object compartments have been cleaned.
Additional info from about:memory
¦ +—–115,536 B (00.31%) — compartment(file:///C:/DirPath/HTML2/main.xml, file:///C:/DirPath/HTML2/object1.html)
¦ ¦ +—98,304 B (00.26%) — gc-heap
¦ ¦ ¦ +–71,856 B (00.19%) — arena/unused [2]
¦ ¦ ¦ +–26,448 B (00.07%) — sundries [2]
¦ ¦ +—17,232 B (00.05%) — other-sundries [2]
and under window-objects
¦ +——3,544 B (00.01%) — top(file:///C:/DirPath/HTML2/object1.html, id=23)/active/window(file:///C:/DirPath/HTML2/object1.html)/dom [2]
¦ +——3,544 B (00.01%) — top(file:///C:/DirPath/HTML2/object1.html, id=21)/active/window(file:///C:/DirPath/HTML2/object1.html)/dom [2]
¦ +——–896 B (00.00%) — top(none)/detached/window(file:///C:/DirPath/HTML2/main.xml)/dom [2]
There are no ghost windows reported.
Each time the main.xml document is loaded and the tab deleted, further compartments are generated and leaked.
The leak only occurs when the xsl transform is used. E.g if a main.html doc is used instead of the main.xml, no leaked compartments are observed.
Thanks for the detailed info. I’m glad FF15 is mostly working well for you.
Transient red messages in about:memory are usually due to https://bugzilla.mozilla.org/show_bug.cgi?id=725248. It’s a very minor problem and not worth worrying about so long as they recur.
As for the XML issue, can you file a bug in bugzilla.mozilla.org and CC me (“:njn”)? Having the example file will make this much easier to reproduce. Alternatively, email me the file and I’ll file the bug. Thanks.
I have emailed a zip containing the files for the xml case.
Thanks for (a) a clear and detailed bug report and (b) an excellent reduced test case. I’ve filed https://bugzilla.mozilla.org/show_bug.cgi?id=791593, CC yourself if you want to follow progress.
Hi Nicholas,
I still suffer from occasional zombie compartments with corresponding ghost windows. I suspect a faulty extension which the anti-leak mechanism introduced in Fx15 doesn’t cover. Is there an alternative to bisecting all extensions? I use all of my 19 extensions daily so it would be a huge nuisance having to deactivate half (and potentially more) just to uncover the culprit. The cycle collector analyzer looks like a good start, but so far I’m rather confused how to proceed after running an analysis and limiting the result set to zombie documents/HTTP elements. Any ideas? Or better yet: A tutorial how to track down misbehaving extensions with CCA?
There’s no good alternative to bisection, unfortunately. I don’t even know how to use the cycle collector analyzer myself! It’s a difficult tool for non-Gecko experts.
If you post the list of add-ons I might be able to give you a suggestion which ones are suspicious. (For example, GreaseMonkey is always suspicious, if you have it installed.)
Also, if you are able to identify concrete steps to reproduce, that makes the bisecting easier. But if the zombies only show up after a while, that can be difficult.
Sorry for the lack of a better suggestion.