306834 - Sunbird uses 100% CPU when idle

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[gekacheka]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050901 Mozilla Sunbird/0.2+

Sunbird is using 100% cpu (w2k task manager) when idle.   It still responds to
mouse clicks.  Occurs with old or new profile.

CPU is at 100% if sunbird application window exists, even if it is minimized to
task bar.
CPU goes to 0% if sunbird application window is closed and only Javascript
Console window is open.

Problem appeared between nightlies of 20050830 (ok) and 20050831 (100% cpu) and
still appears in 20050901.

Bonsai says there were no calendar checkins on 20050830, so may be caused by
interaction with a change outside the calendar code.



Reproducible: Always

Steps to Reproduce:
1. start sunbird


Actual Results:  
CPU at 100% (task manager task bar gauge)

Expected Results:  
CPU at 0%

Comment 1

[pnj]

In addition to using 100% CPU, Sunbird will slowly grow in memory usage.  After
12 hours memory usage was reported at over 300,000K on win XP.

Build - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050906
Mozilla Sunbird/0.2+

Comment 2

[Robin Edrenius]

(In reply to comment #0)
> Actual Results:  
> CPU at 100% (task manager task bar gauge)
> 
> Expected Results:  
> CPU at 0%

This is WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050911 Mozilla Sunbird/0.2+

Comment 3

[Jason Chu]

I can confirm with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050924 Mozilla Sunbird/0.2+

Comment 4

[jrx]

Using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051004
Mozilla Sunbird/0.2+

I get CPU usage of 98-99%.

Comment 5

[Brock Haywood]

I have noticed a similar problem on winxp with latest build.  although my cpu usage is not 100%. it tends to be about 40-50% and is sporadic. i only notice this behaviour once every week or two.  i have to reboot my computer for it to go away, restarting sunbird is not enough. i thought maybe this was a dup of 311223?

Comment 6

[Brock Haywood]

I have noticed a similar problem on winxp with latest build.  although my cpu usage is not 100%. it tends to be about 40-50% and is sporadic. i only notice this behaviour once every week or two.  i have to reboot my computer for it to go away, restarting sunbird is not enough. i thought maybe this was a dup of 311223?

Comment 7

[jrx]

I find CPU usage very erratic - it jumps to 99% with some builds but not others (and sometimes restarting my computer helps, but sometimes I have to install a different build).

Comment 8

[Tom Fitzpatrick]

This happens to me as well.  I believe I've found the cause and posted it under Bug #314752

Comment 9

[Joey Minta]

Attachment: ugly patch

Testing in IRC with someone (Tom72) who could reproduce the problem confirmed that this is a solution.  It isn't pretty, but in terms of getting 0.3a1 out, I'd much prefer to see this ugly hack than a substantial number of users getting their CPU pegged at 100%.

Comment 10

[Michiel van Leeuwen (email: mvl+moz@)]

Comment on attachment 201791 [details] [diff] [review]
ugly patch

r=mvl, but also add a comment to this bug, and explain here what you diagnosed, and why this is the solution.

Comment 11

[Robin Edrenius]

*** Bug 314752 has been marked as a duplicate of this bug. ***

Comment 12

[Joey Minta]

Patch checked in.  If anyone continues to experience this in tomorrow's nightly or later, please re-open.

Problem/diagnosis
We discovered that the setTimeout being fired in update_date() was continually being called too early in the builds experiencing this problem.  According to bug 291386, this can happen when setTimeout is used during heavy-loading.  In an attempt to offset the time-length to compensate for this, the algorithm used actually over-compensates, leading to a much more rapid firing of the timeout than desired.  Probably due to the fact that we rebuild the event-tree every time this timeout is called, we were perpetually in that heavy-loading state, resulting in the infinite loop of rapid setTimeout returns.  Using an nsITimer seems to avoid the over-compensation issue.

In the future, we should at least prevent the unifinder from double-loading on startup, as it does now, and work on other ways to reduce our start-up load.  Hopefully however, bug 291386 will be fixed in the near future, rendering all of this moot.

Comment 13

[Simon Paquet [:sipaq]]

*** Bug 314530 has been marked as a duplicate of this bug. ***

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to comment #0)
>
> Sunbird is using 100% cpu (w2k task manager) when idle.   It still responds to
> mouse clicks.  Occurs with old or new profile.
> 
> CPU is at 100% if sunbird application window exists, even if it is minimized to
> task bar.
> CPU goes to 0% if sunbird application window is closed and only Javascript
> Console window is open.
> 
> Problem appeared between nightlies of 20050830 (ok) and 20050831 (100% cpu) and
> still appears in 20050901.
> 
> Bonsai says there were no calendar checkins on 20050830, so may be caused by
> interaction with a change outside the calendar code.

Curiously, no further mention of a checkin causing this problem or making it more probable. Do the experts here still feel a checkin is involved?  If so was the checkin window proved to be 200508030-20050831?

I'm asking because the problem mentioned in bug 319219 may have gotten worse in the same time frame and is also impacted by timer bug 291386 (which Joey mentions in comment 8).

Comment 15

[Joey Minta]

(In reply to comment #14)
> Curiously, no further mention of a checkin causing this problem or making it
> more probable. Do the experts here still feel a checkin is involved?  If so was
> the checkin window proved to be 200508030-20050831?

Certainly at some point a checkin was involved, but I am nearly certain that it was not in this range.  The manifestation of this bug was sporadic, depending on system resource load at startup time, as explain in the bug I previously cited.

> I'm asking because the problem mentioned in bug 319219 may have gotten worse in
> the same time frame and is also impacted by timer bug 291386 (which Joey
> mentions in comment 8).

The basic idea here is that any checkin that increases the amount of computation/system resources required at startup will cause this bug to appear more often.  At least, that's as far as I understand it.