Closed Bug 251111 Opened 21 years ago Closed 19 years ago

complete crash when I come back to windows xp from standby or hibernate (resume)

Categories

(Firefox :: Shell Integration, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 213637

People

(Reporter: travismars, Assigned: bugs)

Details

(Keywords: crash, stackwanted)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.8 When I put Microsoft Windows XP into Standby, and come back after 15 minutes or more, Firefox crashes without any error report - windows just disappear. This is the only program on my system that does this. Reproducible: Always Steps to Reproduce: 1. Open 1 or more windows of Firefox 0.9 2. Put Windows XP into Standby 3. Wait about 15 minutes and log back into windows. 4. Click on a Firefox window in the tray, and watch Firefox close and disappear Actual Results: Firefox crashed and closed. Expected Results: Alerted me of an error, and bookmarked open web sites OR just opened up again without crashing. Build tools Compiler Version Compiler flags $(CYGWIN_WRAPPER) cl 12.00.8804 -TC -nologo -W3 -nologo -Gy -Fd$(PDBFILE) $(CYGWIN_WRAPPER) cl 12.00.8804 -TP -nologo -W3 -nologo -Gy -Fd$(PDBFILE)
Keywords: crash
I can report similar behaviour with Mozilla 1.8a4 on wake-up from hibernation in WinXP, though in my case there are plenty of error messages. Mozilla 1.8a4 crashes, generating Talkback. Talkback incident IDs: TB1120678W TB1099614Y Behaviour not observed with 1.7b. I am currently searching for a closer match to my bug before filing a new report...
Whiteboard: TB1099614Y TB1120678W
comment 1 is covered in bug 262920. Scott, can you post Talkback ID or a debug stack trace ?
Keywords: talkbackid
Whiteboard: TB1099614Y TB1120678W
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 and Thunderbird version 0.8 (20040913) have the following problem on Windows XP home edition: returning from the sleep mode (standby) takes up to 10 min and after that Firefox (and/or Thunderbird) takes ~100% of CPU time. Impossible to use on a laptop because of this!!!
Misha's comment (#3) is actually bug #265172 (https://bugzilla.mozilla.org/show_bug.cgi?id=265172) -- no crash, but many minutes (I've seen up to 20!) of CPU-maxing after waking from standby or hibernation. (Misha, please vote there to get the problem higher prominence.)
After getting back from hibernation, on Windows XP (Windows XP Home Edition, Version 2002, Service Pack 2) on Intel Pentium (M) 1.5 GHz, 512MB RAM, my laptop just hangs due to excessive usage ~ 100% of CPU by Firefox. The Allocated memory keeps on increasing and there is no remedy to it other than to close firefox forcibly. No other application behave this way.
My Bug 262920 may be of interest; in a comment, Stephen Donner posted what I guess is a dump of one of my Talkback reports (maybe this goes to the "stackwanted" keyword). Bug 262920 was closed because I stopped being able to reproduce the bug when I went to Suite 1.8a5. If people are still experiencing this reproducibly with Firefox, I'd suggest that this be considered a data-loss-causing blocker for the next version.
I can confirm peculiar behaviour (with 100% CPU usage) on my two XP systems too (both P4, 512 MB ram). It takes 10 seconds to 10 minutes to wake up from standby/hibernation (both) and then it uses all the CPU for a few minutes. For me, the more tabs are open, the more time it takes (usually, with only one tab it works pretty much OK). It could be (probably is) something with memory usage or system paging.
I have tried to reproduce this problem 100 times (I counted) since June 1, 2005 until today with debug builds of deerpark on this machine: Satellite P35 - Mobile Intel Pentium 4 3.20 GHZ Total physical memory 512 (448 because of shared video memory) Microsoft Windows XP Home Edition 5.1.2600 Service Pack 2 Build 2600 x86 Family 15 Model 3 Stepping 4 GenuineIntel ~3200 Mhz SMBIOS Version 2.31 I have had no luck; however, I have had it hang once trying to come back from hibernation without Firefox. I contacted Misha of comment #3 and he tried to reproduce his problem again with no luck. From Misha although, it is strange that i was not able to reproduce the bug... btw, this is what i have: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0. The reports of the 100% CPU usage could be from any number of the following: Microsoft Windows Operating Systems Possible Common Occurrences that could cause / contribute to this: Viruses and other Malware Hardware failure Corrupt files Especially Web browser Cache files Adobe Reader Opening Adobe Reader PDF files malformed, corrupted or not supported by your installed version of Reader Hidden pop up windows from other applications and services Instant Messaging Virus Updates Windows Update Microsoft Office Installer Printer Timeouts and other Print System Messages An Automatic Update being done: Microsoft Virus Software Vendor Adobe Automatic Update ( my favorite usual suspect) Screen Saver problems System Services (a common method to check is to run msconfig) MDM or Machine Debug Manager 16 bit Windows applications and DOS / Command Prompt Hangs Using Explorer with Find in Compressed Files Often Times when there is a problem, the performance monitoring and other tools can give you a less than accurate picture of your environment
Let me add my voice here. Firefox also crashes consistently, a few minutes after bringing Windows back from hibernation (don't know about standby). I'm using Firefox 1.5.0.1 on Windows XP SP 2 on a Dell Inspiron 6000 laptop. I get both a Windows error message and the Talkback window. I've sent in quite a few incident reports. Don't know the ID's (how do I start Talkback without crashing Firefox?)
Nickolay: thanks for the tip. Unfortunately it didn't help much. talkback.exe is not in the described location on my computer (it's in C:\Program Files\Mozilla Firefox\extensions\talkback@mozilla.org\components), and when I run it it acts as though it's the first time I'm running it, and there are no incidents listed. However, I found that if you go to http://talkback-public.mozilla.org/search/start.jsp and search for hibernate or hibernation in the comments you'll find a whole bunch of incidents which should be helpful. Seems to be a real structural problem.
possibly a dup of bug 213637 or bug 265172 (which involves flash) not related: bug 363163, which is about XBL Pepijn, Eric, Misha, (you are the only ones left) using a new version of firefox, like v2 or trunk build, do 1. your symptoms agree with bug 213637? 2. you still see a crash ? 3. is only symptom high cpu? Pepijn, If no talkbackids are listed then perhaps prior crashes did not occur on the version of FF you currently have installed. 3 other ways to get your talkback ids: * to get talkbackids from PC, install mosop's "mini-NTT" http://forums.mozillazine.org/viewtopic.php?p=2689548#2689548 * to get talkbackids from PC, install NTT extension http://users.blueprintit.co.uk/~dave/web/firefox/nightly and use the talkback menu item * to get talkbackids from talkback server, when crash occurs on your PC include a unique text string at the beginning of the crash comments like "peppijn", then later go to http://talkback-public.mozilla.org/search/start.jsp and set "search by" to comments, put pepijn in the search field, click search - it may be slow but it will return all your crashes.
Summary: complete crash when I come back to windows xp from standby → complete crash when I come back to windows xp from standby or hibernate (resume)
Hello, After Firefox Version 2, I no longer noticed this EXACT bug. Today the only bug I see that is related to this is bug 213637. Although this is annoying, after Firefox crashes, previously opened websites are remembered, which is a big step. I am marking this as a duplicate of bug 213637, as that is the relevant issue today.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.