User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 Build Identifier: http://www.mozilla.org/products/thunderbird/releases/1.5beta2.html I am currently running both Thunderbird and Firefox on an IBM Thinkpad T41 (1.6 GHz Pentium M, 512 MB ram) with Windows XP SP2. I have noticed for at least the last year that, after resuming from suspend, Thunderbird (or Firefox) will be using 100% of the CPU cycles. (As a side effect, this causes the resume process to be very slow.) The only way to correct the problem is to exit the application and restart it. This problem happens perhaps 20-30% of the time I turn on my computer, but it has been happening consistantly for as long as I've been using the product. Reproducible: Sometimes Steps to Reproduce: 1. Run Thunderbird (or Firefox) 2. Put Windows into Standby mode 3. Resume from Standby Actual Results: CPU utilization is at 100%. Expected Results: CPU utilization should not be at 100%.

*** This bug has been marked as a duplicate of 76831 ***

Looking at bug 76831, I don't think this is the same bug. From the description of 76831: "when I come to restor the window to maximal size afterwards, the Windows titlebar appears, but it can take 20 seconds or more for Mozilla to redraw the rest of the page." The problem I'm experiencing is not that Mozilla is unresponsive -- it appears to be performing just fine -- but that its CPU utilization is at 100%, making other applications perform poorly. Additionally, the CPU usage stays at 100% until I exit the application, not just until Windows is done paging in the application.

WFM but could be hardware specific. Is there anyone else that can test on a Thinkpad?

My department at school provides everyone with Thinkpads, so I know a number of people with the exact same configuration as me... I'll check with them and see if anyone is having the same problem.

The fix in bug 76831 should resolve this issue. 76831's fix (checked in around July) was to remove the option to trim memory on minimze which would often cause issues not unlike this when Fx or Tb was reopened after long periods of inactivity. If you still don't think it's a dupe of 76831, then it's a dupe of bug 299202 ;)

I've confirmed at least one additional instance of someone running on the same configuration (e.g. Thinkpad). I'll start using the latest build and see if I continue to see the problem.

I've just confirmed that the bug still exists on the Oct. 11th nightly build.

I can confirm this. The following is also true: - This happened on my Dell Inspiron (I no longer have this machine) - This happens on my current laptop (Asus based; home-built) - 100% CPU is used (sometimes, I'd say that 20-30% is probably quite accurate) on resume from both sleep (suspend to RAM) and hibernate (suspend to disk) - I'm using: ff1.5, tbird1.5 it still hapens with both of these (It happened in the 1.0x series, too) - This affects ALL mozilla-based software (as far as I can tell): I've seen my CPU split 4 ways (~25% each): 1/4 FF, 1/4 TBird, 1/4 Sunbird, 1/4 Komodo HTH. I can perform any tests you like, but this bug is extremely annoying. Especially, as the OP said: it impedes system resume (makes it EXTREMELY slow, sometimes). S

I have this same problem. Firefox and/or Thunderbird make my Compaq laptop (running XP SP2 though it happened before SP2 as well) come out of standby very slowly, and once it finally gets out of standby I can see the problem had been that one or both of them had been using 100% CPU. No other applications do this. It is *nearly* enough for me to want to uninstall Mozilla stuff from my machine, but I can't bring myself to. The thread that seems to be using the CPU most heavily when this happens is running nspr4.dll, if that is of any help at all. This has happened with 1.0.x versions and continues to happen with the 1.5 line ... I've just come to live with it, but it is a real pain.

This may be related to bug 265172 and bug 290963. I can report that my Firefox 1.5 (Build 2005111116) does often have 95% CPU after resuming from suspend mode.

This problem continues to plague my laptop. I hate to complain without providing some sort of help. I don't, however, have any clue about how to go about supporting this bug. Is there anything I can do when this happens (before or after it happens, even) that can help developers? I don't mind installing extra extensions/diagnostic tools/etc. Short of diving into the code, is there anything I can do to help? S

This is a screengrab from Process Explorer showing the top thread chewing away. I hoped the list of .dlls might help ring a bell with someone in the know on the development team (or elsewhere).

*** This bug has been marked as a duplicate of 265172 ***