High CPU use when viewing comments at CNN.com

RESOLVED WORKSFORME

Status

()

Core
General
RESOLVED WORKSFORME
10 years ago
a year ago

People

(Reporter: Steve Chapel, Unassigned)

Tracking

({perf, regression})

Trunk
x86
Windows XP
perf, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

10 years ago
Reproducible: Always

Steps to Reproduce:
1. Go to http://www.cnn.com/2007/SHOWBIZ/TV/12/20/nickelodeon.spears.ap/index.html?iref=newssearch 
2. Scroll down to near the bottom of the page and click the Next 25 comments link
3. Repeat step 2 two or three times

Quickly the CPU usage reaches 99% and Firefox's user interface locks up. This was first reported at <http://forums.mozillazine.org/viewtopic.php?t=615017> and is explained as a regression from Firefox 1.5 that is present in Firefox 2 and Firefox 3.
Regression window is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-08-03+07%3A00&maxdate=2006-08-04+07%3A00
On Vista it is not as clear, doesn't really hang but gets only very slow, if you are patient, it loads finally.
Caused by bug 345736? JS bug that was also checked in on branch.
Blocks: 345736
(In reply to comment #1)
> Regression window is
> http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-08-03+07%3A00&maxdate=2006-08-04+07%3A00
> On Vista it is not as clear, doesn't really hang but gets only very slow, if
> you are patient, it loads finally.
> Caused by bug 345736? JS bug that was also checked in on branch.

Sorry, need more evidence. That bug's patch is to the JS parser and it does not lead to lengthy loops. It affects code enabled only by opt-in versioning (JS1.7, let as a context-sensitive keyword). I think we need a back-out from the guilty hook that we can prove caused this bug.

/be
> 

No longer blocks: 345736
Did also a check on the branch and there are 4 bugs in common:
bug 330689, bug 346936, bug 336592, bug 345736. 

Comment 4

10 years ago
Results due to a patch to the fix for 
<a>Bug 347054 <href=https://bugzilla.mozilla.org/show_bug.cgi?id=345736></a>
 – crashes finalizing plugin scriptability objects inside js_GC [@ _PR_MD_ATOMIC_DECREMENT] [@ _PR_DarwinPPC_AtomicDecrement()] [@ 0x6c707538] (edit)

Comment 5

10 years ago
The thread that is causing excessive CPU usage seems to be firefox.exe!jpeg_fdct_islow

Comment 6

10 years ago
A smaller regression window on Mozilla 1.8 branch can be found and is 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-04+02%3A40&maxdate=2006-08-04+09%3A00&cvsroot=%2Fcvsroot
I am not sure, but the sun calendar event in mozilla/calendar/prototypes/wcap/sun-calendar-event-dialog.js could be making excess eventlistener calls in v1.1.2.6:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/calendar/prototypes/wcap&command=DIFF_FRAMESET&file=sun-calendar-event-dialog.js&rev1=1.1.2.5&rev2=1.1.2.6&root=/cvsroot

Comment 7

10 years ago
Good BuildID on mozilla_1_8 branch is 2006080403 and problem one is 2006080409.
If you copy the browser.manifest file in firefox\chrome from 2006080403 and paste it into newer version(s), the problem seems to be resolved/worked around. The ordering of first 3 declarations that works good is:
content browser jar:browser.jar!/content/browser/ xpcnativewrappers=yes
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
content branding jar:browser.jar!/content/branding/ xpcnativewrappers=yes
the one that causes problems is:
content browser jar:browser.jar!/content/browser/ xpcnativewrappers=yes
content branding jar:browser.jar!/content/branding/ xpcnativewrappers=yes
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul

Comment 8

9 years ago
Opening the original poster's CNN link and clicking next 25 a couple times did cause my Firefox 2.0.0.14 to use up 50% of the CPU (on my dual core Intel Core 2 Duo) initially, but even if I switch back to that still-open window, it no longer takes up much of the CPU (though some)

However... the same thread "FIREFOX.EXE!jpeg_fdct_islow" will eventually eat up 50% of my CPU when I open enough windows+tabs - every time. I inevitably open up a fair number of windows+tabs, and always (lately, not sure if it was doing it *immediately* after my clean Win XP Pro SP2 (all patched) install or not, but surely soon after, if not immediately)

I've seen a number of other posts on the forums and stuff, but no apparent solution or work-around or anything like that. Is there any, that anyone knows of? I don't know if I can help any further than the above info and possibly testing. I can debug a simple C, C++, C#, etc. prog, but I'm not sure I could even get Firefox to compile under windows, let alone debug it. (since it probably won't compile under Visual Studio 2005/2008)

I would recommend that someone immediately go to the code and replace the "FIREFOX.EXE!jpeg_fdct_islow" with a "FIREFOX.EXE!jpeg_fdct_isFAST" ! (j/k! (sorry!))
(In reply to comment #8)
> Opening the original poster's CNN link and clicking next 25 a couple times did
> cause my Firefox 2.0.0.14 to use up 50% of the CPU (on my dual core Intel Core
> 2 Duo) initially, but even if I switch back to that still-open window, it no
> longer takes up much of the CPU (though some)

those steps WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre

Comment 10

9 years ago
I tracked down this issue, and it looks like it's caused by the spell-checker module.

If you turn it off from Tools->Options->Advanced->"Check my spelling as I type" it no longer causes the high CPU usage in that CNN webpage.

Try it yourself.
Ref comment #10, indeed.. turning off spell-check does fix the hang/high CPU use and you can load the next 25 comments as fast as you want, no hang.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008051502 Minefield/3.1a1pre Firefox/3.0 ID:2008051502

Comment 12

a year ago
The original URL that was provided with this bug is not available anymore. I tested this scenario with the below URL on CNN that contained several hundred comments and I loaded several of them one by one but did not see any substantial increase in CPU usage by firefox.exe even with discussed "spell check" configuration checked. It remained below 5% on an Intel Core I7-4810MQ CPU @2.80 Ghz box.

URL tested: http://www.cnn.com/2016/04/06/opinions/presidential-race-after-wisconsin-opinion-gergen/index.html

Tested on:

Name 	Firefox
Version 	46.0b4
Build ID 	20160322075646
User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0


Closing the defect as "RESOLVED - WORKSFORME".
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WORKSFORME

Comment 13

a year ago
(In reply to Kanchan Kumari QA from comment #12)
> The original URL that was provided with this bug is not available anymore. I
> tested this scenario with the below URL on CNN that contained several
> hundred comments and I loaded several of them one by one but did not see any
> substantial increase in CPU usage by firefox.exe even with discussed "spell
> check" configuration checked. It remained below 5% on an Intel Core
> I7-4810MQ CPU @2.80 Ghz box.
> 
> URL tested:
> http://www.cnn.com/2016/04/06/opinions/presidential-race-after-wisconsin-
> opinion-gergen/index.html
> 
> Tested on:
> 
> Name 	Firefox
> Version 	46.0b4
> Build ID 	20160322075646
> User Agent 	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101
> Firefox/46.0
> 
> 
> Closing the defect as "RESOLVED - WORKSFORME".

I do not know if this can be closed - because on CNN, there is no longer any comments section! So the underlying issue could very well exist!!
You need to log in before you can comment on or make changes to this bug.