Last Comment Bug 778368 - TeX the World Greasemonkey script makes FF15 slow, use 100% cpu and 750MB of memory
: TeX the World Greasemonkey script makes FF15 slow, use 100% cpu and 750MB of ...
Status: RESOLVED WONTFIX
[sps][3rd-party-bustage][MemShrink:P3]
: mlk
Product: Tech Evangelism
Classification: Other
Component: Add-ons (show other bugs)
: unspecified
: x86 Windows Vista
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-27 17:11 PDT by mike
Modified: 2012-08-15 12:16 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description mike 2012-07-27 17:11:11 PDT
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 1.4.2.1
- Extended Statusbar 1.5.8 (Disabled)
- Extension List Dumper 1.15.2
- Fast Dial 4.2.2
- FEBE 7.0.3.5
- Firebug 1.10.0
- FoxClocks 2.10.85
- FoxTab 1.4.5
- Gecko Profiler 1.8.5 (Disabled)
- Ghostery 2.8.0.2
- 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.
Comment 1 Loic 2012-07-27 18:07:23 PDT
You have a ton of add-ons, the culprit is likely here.
Comment 2 mike 2012-07-28 19:46:50 PDT
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.
Comment 3 Loic 2012-07-29 00:28:30 PDT
Try in safe mode (http://kb.mozillazine.org/Firefox_Safe_Mode), please.
Comment 4 José Jeria 2012-07-29 03:15:26 PDT
(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.
Comment 5 (mostly gone) XtC4UaLL [:xtc4uall] 2012-07-29 05:58:10 PDT
Maybe provide about:memory Output Idle vs. Bugtime?
Trying to repro against Nightly?
Comment 6 Andrew McCreight [:mccr8] 2012-07-29 07:24:21 PDT
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?
Comment 7 mike 2012-07-29 16:25:52 PDT
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.
Comment 8 Andrew McCreight [:mccr8] 2012-07-29 17:37:20 PDT
What are the names of all of the Greasemonkey scripts you are using?
Comment 9 mike 2012-07-29 21:59:19 PDT
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 :)
Comment 10 Andrew McCreight [:mccr8] 2012-07-30 06:17:41 PDT
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.
Comment 11 mike 2012-08-02 18:04:38 PDT
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
Comment 12 Andrew McCreight [:mccr8] 2012-08-02 18:10:39 PDT
(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.
Comment 13 mike 2012-08-03 10:47:53 PDT
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)
Comment 14 Justin Lebar (not reading bugmail) 2012-08-03 10:50:37 PDT
> 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.
Comment 15 Jorge Villalobos [:jorgev] 2012-08-03 11:00:10 PDT
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?
Comment 16 Kris Maglione [:kmag] 2012-08-03 13:08:21 PDT
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.
Comment 17 Justin Lebar (not reading bugmail) 2012-08-03 13:14:20 PDT
(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.
Comment 18 Justin Lebar (not reading bugmail) 2012-08-07 19:04:47 PDT
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 
> avital@thewe.net or just go do it :)
Comment 19 Andrew McCreight [:mccr8] 2012-08-07 19:09:22 PDT
Great!
Comment 20 Kris Maglione [:kmag] 2012-08-15 12:16:32 PDT
This seems like the best we're going to get.

Note You need to log in before you can comment on or make changes to this bug.