Closed Bug 306834 Opened 15 years ago Closed 14 years ago

Sunbird uses 100% CPU when idle

Categories

(Calendar :: General, defect)

x86
Windows 2000
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gekacheka, Assigned: jminta)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

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%
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+
(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+
I can confirm with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050924 Mozilla Sunbird/0.2+
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%.

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?
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?
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).
This happens to me as well.  I believe I've found the cause and posted it under Bug #314752
Attached patch ugly patchSplinter Review
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%.
Assignee: mostafah → jminta
Status: NEW → ASSIGNED
Attachment #201791 - Flags: first-review?(mvl)
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.
Attachment #201791 - Flags: first-review?(mvl) → first-review+
*** Bug 314752 has been marked as a duplicate of this bug. ***
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.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
*** Bug 314530 has been marked as a duplicate of this bug. ***
Depends on: 291386
(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).
(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.
You need to log in before you can comment on or make changes to this bug.