351818 - 100% CPU usage on this site, with test case

Status: RESOLVED WORKSFORME

(Core :: General, defect)

Description

[Marco Bonardo [:mak]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1b2) Gecko/20060907 BonEcho/2.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1b2) Gecko/20060907 BonEcho/2.0b2

A user on the forum (Stenna) reported a 100% cpu usage on his site, and provided a test case here:

http://www.msoft.be/index.old.htm

confirmed by different users on this topic, where other infos are available:
http://forums.mozillazine.org/viewtopic.php?p=2477507

Reproducible: Always

Steps to Reproduce:
1. Load page


Actual Results:  
CPU usage go to 100% till you can someway close the tab containing the site, closing the tab come back to normal cpu usage

Expected Results:  
cpu usage stay low

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060908 Minefield/3.0a1
I see this problem indeed in BonEcho, but it is fixed on trunk.
Still using a lot of CPU time, but not a hang anymore.

Fixed in this period: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-05-12+12%3A00&maxdate=2006-05-12+16%3A00
By Bug 337752, or Bug 332644 ?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Simplified testcase with 100% cpu load

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

It has something todo with Javascript. I attached a simplified testcase.

Comment 4

[Martijn Wargers (dead)]

Thanks for that simplified testcase, Henrik. The only problem is that it also gets 100% cpu load on trunk, so there is no difference between trunk and branch with that testcase.
That testcase seems to indicate that the branch gets drowned in setTimeout and/or setInterval, while the trunk gets not.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #4)
> Thanks for that simplified testcase, Henrik. The only problem is that it also
> gets 100% cpu load on trunk, so there is no difference between trunk and branch
> with that testcase.

This is suspicious. I only removed us much code as I can of the URL mentioned above. So why it also happens now with trunk while not on the URL?

Comment 6

[Boris Zbarsky [:bzbarsky]]

The "simplified testcase" hangs trunk for me (when loaded via jar:), which is not suprising -- init() calls itself a bunch of times; I see us spending all our time inserting timeouts into the timeout list (probably because the number of pending timeouts grows exponentially).

We could mitigate the InsertTimeoutIntoList thing if it were not a linked list... but really, I question whether the minimization is correct.  I don't get the hang on the URL in comment 0.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Profile of the URL in comment 0 shows lots of time spent on restyling and reflow, as sorta expected given the JS ticker thing there...

We should probably file a separate bug on the fact that exponential growth in number of timeouts makes life suck a lot.

Comment 8

[Ria Klaassen (not reading all bugmail)]

FWIW, this regressed between 2004-05-30 09 and 2004-06-02 09 which is a wide range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2004-05-30+07%3A00&maxdate=2004-06-02+10%3A00

Comment 9

[Jesse Ruderman]

> We should probably file a separate bug on the fact that exponential growth in
> number of timeouts makes life suck a lot.

Bug 261633.

Comment 10

[Boris Zbarsky [:bzbarsky]]

No, that bug looks like it devolved into IE-compat stuff where in IE setInterval doesn't set an interval...

I filed bug 352750 on the issue I saw.

Comment 11

[RNicoletto]

Simplified testcase is throwing my CPU at 100%. Bug still valid.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

Comment 12

[Boris Zbarsky [:bzbarsky]]

Not a hang, though.

Comment 13

[Wayne Mery (:wsmwk)]

> CPU usage go to 100% till you can someway close the tab containing the site, closing the tab come back to normal cpu usage

Now, not even 20% (1-2sec) using 58.0b8 on win7.