User Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120724191344 Steps to reproduce: Thanks for FF. For the past >2 months on FF15 nightly, FF15 Aurora, and now FF15b1. Repeatable. When consuming more than 750MB at idle, memory goes up 1 MB/s and after approx 60 secs it goes back down. CPU usage becomes constantly very excessive approaching 100% even with no browsing. Only closing tabs to below 750 MB do things improve. Goto reddit.com and open 10-posts/tabs or more until 750 MB. Wait till idling. Watch FF memory consumption using StatusbarEx or MS Physical Memory Usage History in taskmgr go up 1 MB/s and after approx 60 secs it goes back down. CPU usage becomes constantly very excessive approaching 100% even with no extra browsing. Tab scrolling very sluggish. Only closing tabs to below 750 MB do things improve. What more tools can I use without having to do my own compile ?? I've read a lot about memshrink program and zombie compartments. Short capture using Gecko Profiler during "idling" https://people.mozilla.com/~bgirard/cleopatra/?report=1bd88e205e7a2aee997fd5d823ea7cae556ed6a7 Firebug Profile use to crash FF15n,a. Application: Firefox 15.0 (20120724191344) Operating System: WINNT (x86-msvc) - about:me 0.5 - Adblock Plus 2.1.2 - All-in-One Sidebar 0.7.17 - Aspator 1.103 - Auto Copy 1.0.2 (Disabled) - AutoCopy 2 1.2.5 - BetterPrivacy 1.68 - CacheViewer 0.6.3 (Disabled, Incompatible) - CacheViewer Continued 0.8 - CHM Reader 0.2.3 (Disabled, Incompatible) - CLEO 5.0.1 - Collusion 0.15 (Disabled) - ColorfulTabs 12.7 - Configuration Mania 1.16.2012072101 (Disabled) - CookieCuller 1.4 - Cookies Manager+ 1.5.1 - CoolPreviews 3.5 - Custom Buttons 0.0.5.5 - Dictionary Switcher 1.3.2 - Dictionnaire français «Moderne» 4.3 - Download status 1.7.3 - Download Statusbar 0.9.10 - DownloadHelper 4.9.9 - DownThemAll! 2.0.13 - EPUBReader 22.214.171.124 - Extended Statusbar 1.5.8 (Disabled) - Extension List Dumper 1.15.2 - Fast Dial 4.2.2 - FEBE 126.96.36.199 - Firebug 1.10.0 - FoxClocks 2.10.85 - FoxTab 1.4.5 - Gecko Profiler 1.8.5 (Disabled) - Ghostery 188.8.131.52 - Greasemonkey 0.9.20 - HTTPS-Everywhere 2.1 - Image Zoom 0.4.6 - Memory Restart 1.9 (Disabled) - Microsoft .NET Framework Assistant 0.0.0 (Disabled) - Mozilla Archive Format 2.0.6 - Mozilla Labs: Prospector - OneLiner 2 (Disabled) - NoScript 2.4.9 - OPIE 4.1 - Reddit Enhancement Suite 4.1.2 - Restartless Restart 8 - ScrapBook 1.5.4 - Session Manager 0.7.9 - Showcase 0.9.5.8 (Disabled) - StatusbarEx 0.3.5 - Tab Mix Plus 0.4.0.3 - Tab Progress Bar 0.6 (Disabled, Incompatible) - Test Pilot 1.2.1 - Tilt 1.0.1 (Disabled) - Toolbar Buttons 1.0 - Tree Style Tab 0.14.2012050301 - United States English Spellchecker 6.0 - User Agent Switcher 0.7.3 - WebMail Notifier 2.9.9 Vista 32, AV off, SuperFetch off, 100 MB FF-cache using RAM, 4 GB RAM. Expected results: During idle: Low CPU/power usage, low memory usage increase.
You have a ton of add-ons, the culprit is likely here.
Maybe, but I'm also looking for the tools to debug this baby. Updated numbers. Wait till idling. Watch FF memory consumption go up 1 MB/s and then it goes back down by 180 MB from 800 MB down to 620 MB after 3 minutes. This goes on at infinitum.
Try in safe mode (http://kb.mozillazine.org/Firefox_Safe_Mode), please.
(In reply to Loic from comment #1) > You have a ton of add-ons, the culprit is likely here. http://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-plugs-the-add-on-leaks/ Culprit is most likely there, but my understanding is that extensions should no longer cause any leaks in Firefox 15. See article. This is a valid bug.
Maybe provide about:memory Output Idle vs. Bugtime? Trying to repro against Nightly?
Do you get the same problems if you disable Greasemonkey? In bug 778318 a user reported memory problems with that running, though your memory problems aren't the same. The profile shows that the spikes are from nsSVGAnimateTransformElement::ParseAttribute. I'm not sure what might be doing that. > Culprit is most likely there, but my understanding is that extensions should no longer cause any leaks in Firefox 15. Addons can still consume memory, they just can't hold onto pages forever (excluding bugs in Firefox), which is the most common cause of massive addon memory leaks. What you are experiencing is smaller, and is happening without browsing, so it seems like something different. Could you attach a file containing what about:memory?verbose looks like when memory is at its highest?
I've got good and bad news: Disabling GreaseMonkey worked ! The bad news is that FF now increases by 1KB/minute :p (bad humor!). That was quick and easy considering I had all other addons still workin' And the cigar goes to Andrew* Note * ... and to the FF team, FF users, and google $$ I will be checking if it was a script for GM or if it is GM itself. I've now only lost the zoom-image-via-mouse functionality of that GM script-software. I will also check Reddit RES which is where I believe where this script was copied from; maybe script kiddy. Stay tune and have a nice weekend.
What are the names of all of the Greasemonkey scripts you are using?
1, tex_the_world(.js) // ==UserScript== // @name TeX the world // @namespace http://thewe.net/tex // @description TeX the world // @include * // ==/UserScript== 2. imagedragresize(.js) (note: I excluded reddit sites to make sure it doesn't double-do what RES for GM does) // ==UserScript== // @name ImageDragResize // @namespace C:\Users\m\Documents\ImageDragResize.js // @include about:addons // @name Drag to Resize // @namespace http://kylej.name/ // @description Drag to resize images, based on code in the RES. // @author Kabaka // @include * // @exclude http://www.chess.com/* // @exclude http://chess.com/* // ==/UserScript== 3. RES (disabled) Pls keep me informed :)
Oh, I bet it is TeX the World. I've seen this addon cause severe performance problems for people before. What it does is take the contents of every tab, turn it into a string, then search the string. It does this every 3 seconds, or so. That's a lot of data to create all the time! Try enabling Greasemonkey, but disabling TeX the World, and see if that is still fixed. Maybe we could improve the memory behavior a bit by running the GC more, but I bet this is just going to cause a lot of CPU usage no matter what. I bet TtW is using this ParseAttribute thing that seems to take up the entire profile.
Yep it was Tex the World. I reenabled grease monkey. I haven't tried RES on GM. There should be an easily findable list of cpu or memory "suspicious" plugins, extensions, GM scripts, or other. Also, how about putting lower priority on loading background tabs :) Thanks
(In reply to mike from comment #11) > Yep it was Tex the World. I reenabled grease monkey. I haven't tried RES on > GM. Great, thanks for letting me know! > There should be an easily findable list of cpu or memory "suspicious" > plugins, extensions, GM scripts, or other. Yes, that is something that would be very useful, but unfortunately it is also very difficult. We're slowly building towards the point where we can get that information. After we have it, we'll have to put it somewhere that is easy for a user to figure out. > Also, how about putting lower priority on loading background tabs :) There's already some work along these lines to keep webpages from going crazy, but I'm not sure it would help in this particular case, because addons aren't really associated with a particular tab.
I guess you can close this bug. > > Also, how about putting lower priority on loading background tabs :) > > There's already some work along these lines to keep webpages from going > crazy, but I'm not sure it would help in this particular case, because > addons aren't really associated with a particular tab. Or, what about throttling bandwidth to hidden tabs :p It's a pain on a laptop when using power saving. Very jerky scrolling. (using 0.8 GHz of a max of 2.2 GHz, 2-core laptop)
> I guess you can close this bug. We'll leave it open until the add-on gets fixed. > There should be an easily findable list of cpu or memory "suspicious" plugins, extensions, GM > scripts, or other. I'd like this too, but getting it to happen has been a political nightmare. I would not hold my breath. For what it's worth, most (certainly not all) add-on problems get resolved within a month or two. But this bug really isn't the right place to figure this out.
According to the developer, the userscript is no longer maintained, but is open for patches: http://thewe.net/tex/. It would likely be better for performance to use the new mutation event listeners rather than a 3 second cycle to parse sites again. Any takers?
It's not an add-on, it's a userscript. How popular is it? To call the vast majority of userscripts 'bad' would be an understatement. Trying to fix them all is not a task we can even begin to take on.
(In reply to Kris Maglione [:kmag] from comment #16) > It's not an add-on, it's a userscript. How popular is it? To call the vast > majority of userscripts 'bad' would be an understatement. Trying to fix them > all is not a task we can even begin to take on. mm, you're right. I'll send an e-mail to the author to ask him to put a disclaimer up on his site.
The author has put a disclaimer up at http://thewe.net/tex/: > BEWARE! TeX THE WORLD causes severe performance problems [link to this bug] on Firefox! If you want > to help fix this, you're welcome to do but I am not maintaing this anymore. Send me an email at > email@example.com or just go do it :)
This seems like the best we're going to get.