199862 - CPU usage goes to 100% after suspend to disk

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Topics Man]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

I after resuming my notebook (Dell Inspiron 7500, PIII, 512MB, 40GB) from
Windows XP's suspend-to-disk feature, the system runs extremely slowy. On
examination this was due to Mozilla having 100% CPU usage after the resume.
Prior to the suspend-to-disk it was running fine, with 5-6 browser windows open
and several tabs open in each one. Also the Venkman debugger was open (though
not active) and the fast-load system tray applet was running. As I'm amazingly
patient ;-), I went through all the tabs in all the browser instances, closing
them one my one. This didnt make any difference (Mozilla.exe still at 100% CPU)
until the final Moilla window (actually the Venkman debugger) was closed. CPU
usage then went down to normal levels. I have seen this happen several times.
The most obvious first symptom is that the computer takes much longer to resume
from 'suspend-to-disk' (eg. it takes much longer get to get back to the XP login
screen when Mozilla was running prior to the suspend-to-disk'), but it doesnt
always cause MOzilla's CPU usage to go to 100% - it could be that this depends
on the amount of time that the PC has been left switched off in
suspended-to-disk state (the only time I have seen Moz go to 100% CPU was when
it was switched off for 2 days, which has only been done once as the PC is
normally used every day).

Reproducible: Always

Steps to Reproduce:
1. Do some normal Browsing in Mozilla
2. Suspend the machine to disk (Windows XP) with Moz still running
3. Resume it again sometime later.

Actual Results:  
1) The computer takes much longer to resume from 'suspend-to-disk' (eg. it takes
much longer get to get back to the XP login screen when Mozilla was running
prior to the suspend-to-disk') compared to 'normal' (ie. MOzilla not running
before the suspend-to-disk).

2) MOzilla's CPU usage may go to 100%, but it doesnt always - it could be that
this depends on the amount of time that the PC has been left switched off in
suspended-to-disk state (the only time I have seen Moz go to 100% CPU was when
it was switched off for 2 days, which has only been done once as the PC is
normally used every day).

3) Sometimes there is also a lot of disk thrashing when Moozilla is brought back
to the foreground, which is strange as the PC has 512MB RAM and is not doing
much swapfile paging. This doesnt always happen - there was no heavy disk
activity when Mozilla was running at 100% CPU load as described above.

Expected Results:  
Work at normal CPU utilisation!

This can cause data loss as the system is sometimes so unresponsive after
resuming from a suspend-to-disk (with MOz running) that it isnt possible to get
back into applications and save data.

Comment 1

[Jo Hermans]

This looks similar to bug 197863, but I really don't know if they're related.

Comment 2

[u63580]

I don't know if this is related, but my notebook (clone-machine, Celeron 1GHz,
Win2k) has a habit of not coming back from sleep when running Mozilla.

Comment 3

[Topics Man]

Is anything being done about this - seems like it could be a major problem for
many, many users (ie. those with notebooks who use its APM features)??

I just spent 2 hours recovering from a slow (ie. about 1% of normal) system when
resumed from disk, which was again down to Mozilla 1.3 - system returned to
normal speed when I was eventually able to close both of my open Mozilla windows.

Can people start voting for this if they've seen these (or similar CPU-overload)
problems happen ?

Comment 4

[Vidar Haarr (not reading bugmail)]

WFM on WinXP SP1 trunk 2003081515.

Reporter: could you try to reproduce this using a recent nightly build from
<http://ftp.mozilla.org/pub/mozilla/nightly/latest/> ? If it works, please
resolve this bug as WFM. Thanks !

Comment 5

[Jon Henry]

Resolving worksforme, it's been 8 months since the last comment from the
reporter and there's a good chance the bug mentioned by Jo fixed the problem. If
this is still happening to you in a post-1.5 build, please feel free to reopen.