Closed Bug 765215 Opened 12 years ago Closed 12 years ago

Firefox 13 hangs on resuming from sleep

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
13 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20

People

(Reporter: gfejer, Assigned: mayhemer)

References

Details

(Keywords: hang, regression, stackwanted, Whiteboard: [testday-20120615] see comments 35, 37, 38, 41)

Attachments

(3 files, 2 obsolete files)

Stack Trace for Aurora 18.0a2 BuildID=20121030042010
84.63 KB, text/plain
Details
NSPR TimeStampWindows
1.99 KB, text/plain
Details
v2
7.19 KB, patch
ehsan.akhgari
: review+
mayhemer
: checkin+
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 Build ID: 20120601045813 Steps to reproduce: Leave Firefox 13 running and close laptop. Laptop is set to go to sleep (not hibernate) on close. Wake up laptop / open cover after some while. O/S is Win 7 Enterprise - Service Pack 1 - 64 bit This is similar in behavior to old & closed (Mac) bugs: 426089 469459 Actual results: Firefox 13 is unresponsive. I can't switch tabs, refresh pages, type into address bar, or access any menu items. To get it going, I have to kill firefox and restart it -- all other software is unaffected. Expected results: Previous versions of firefox just woke up and I was able to continue working as if it had never been put to sleep. Browsing, changing tabs, menus all worked This is expected behavior
Severity: normal → critical
Developers would need a crash report to try and fix this so we need your help. Please review and follow "Firefox crashes - Troubleshoot, prevent and get help fixing crashes"[1] and provide some Crash ID(s) of when you've reproduced the problem. 1| https://support.mozilla.org/en-US/kb/firefox-crashes-troubleshoot-prevent-and-get-help
Whiteboard: [testday-20120615]
I am having the same exact problem. I am using Windows XP. I recently upgraded from Firefox 3 to Firefox 12 and now the latest 13. I had no problems with version 3 but with 12 and 13 I have to restart Firefox every time I wake the computer up from either hibernation or sleep. I also disabled add-ons and have the latest Adobe Flash Player. This happens every time. If I need to submit additional information please give me instructions and I will do so.
I also have this problem (Windows 7, FF 13.1). I had Firebug open when I put my computer to sleep, so I could see what happened when it returned from sleep. It looks to me like Firefox tries to do all the javascript work that it would have done if the computer never slept, all at once. If the computer slept for two hours, and javascript does an update every 5 seconds, it will try to do 1440 updates when returning! I had to actually kill the process because I didn't want to swamp my own server either -- Firebug reported over 8000 request rows that it couldn't display because the log was full by the time I decided to kill it. So in any case, there's a serious problem with Firefox' behaviour when returning from sleep. I understand some applications benefit from having its javascript executed as 'it would have', but seriously, the app developers should take sleeping computers into account, not Firefox. Please just freeze javascript when the computer goes to sleep! :)
(In reply to alex_mayorga from comment #1) > Developers would need a crash report to try and fix this so we need your > help. > > Please review and follow "Firefox crashes - Troubleshoot, prevent and get > help fixing crashes"[1] and provide some Crash ID(s) of when you've > reproduced the problem. > > 1| > https://support.mozilla.org/en-US/kb/firefox-crashes-troubleshoot-prevent- > and-get-help I tried to get crash IDs but the problem is that the program hangs it doesn't crash so there is no report that I could find.
(In reply to bugzilla from comment #3) > I also have this problem (Windows 7, FF 13.1). > > I had Firebug open when I put my computer to sleep, so I could see what > happened when it returned from sleep. It looks to me like Firefox tries to > do all the javascript work that it would have done if the computer never > slept, all at once. If the computer slept for two hours, and javascript does > an update every 5 seconds, it will try to do 1440 updates when returning! I > had to actually kill the process because I didn't want to swamp my own > server either -- Firebug reported over 8000 request rows that it couldn't > display because the log was full by the time I decided to kill it. > > So in any case, there's a serious problem with Firefox' behaviour when > returning from sleep. I understand some applications benefit from having its > javascript executed as 'it would have', but seriously, the app developers > should take sleeping computers into account, not Firefox. Please just freeze > javascript when the computer goes to sleep! :) I do think you have the problem pegged. If I wait long enough before trying to use Firefox after waking from sleep, it does come back to life. I never had this problem with version 3 so I wonder what happened.
(In reply to steve from comment #4) > (In reply to alex_mayorga from comment #1) > > Developers would need a crash report to try and fix this so we need your > > help. > > > > Please review and follow "Firefox crashes - Troubleshoot, prevent and get > > help fixing crashes"[1] and provide some Crash ID(s) of when you've > > reproduced the problem. > > > > 1| > > https://support.mozilla.org/en-US/kb/firefox-crashes-troubleshoot-prevent- > > and-get-help > > I tried to get crash IDs but the problem is that the program hangs it > doesn't crash so there is no report that I could find. Firefox eventually did crash. I was doing nothing with it at the time, I suppose it had just got tired of waiting to come back to life. There is a crash report submitted: http://crash-stats.mozilla.com/report/index/bp-9a430f6a-6331-4401-8a46-f98f42120628. If you need the details, I also saved them but I assume you will have access to them.
I would like to add to this that I am getting the same issues when I am resuming from hibernation on firefox 13.0 and recent 0.1 update affected all 4 machines I own: lenovo T420-windows 7 pro lenovo T420-windows 7 ultimate Desktop-windows 7 ultimate Samsung R620 - windows 7 ultimate all exhibits the same symptom when the firefox is loaded when the machines are hibernated, upon resuming, all other applications are responsive, except firefox. older versions of firefox works okay. looks like I would have to revert versions. I couldn't generate any bug reports as it didn't crash.
I am having this issue as well but only when resuming from hibernation. I open task manager and watch the firefox.exe process load several hundred megabytes into memory. Only when it finishes loading (circa one minute) does Firefox become responsive again. Using Windows 7 Professional Waterfox 13.0 Safe mode and firefox reset did not cure the problem. Any fix is appreciated.
I just loaded version 14 and am still having the same problem. For me it happens with sleep or hibernation and it takes a very long time to come alive. I always have to close Firefox down and restart. When I do that I get a message that says Firefox is already running and I have to try to restart it again. This can happen a number of times before it finally starts up. Using Windows XP Gateway laptop M350WVN
Exactly the same issue here with version 13 as well as 14 on Windows 7 as well as Windows XP/SP2. THIS ERROR IS ANNOYING, especially when you frequently hibernate (eg on a Laptop) and want to resume work - just to find all the tabs with articles you just have been reading frozen. Currently my workaround is to use Firefox 11, which is not quite stable on flash videos (YouTube).
I can confirm this bug too, with Firefox 15.0 on Windows XP after hibernate. No response from Firefox when changing tabs. But after switching to another program that obscures the Firefox window, Firefox will redraw the window after switching back to Firefox.
(In reply to Maarten Deen from comment #11) > I can confirm this bug too, with Firefox 15.0 on Windows XP after hibernate. > No response from Firefox when changing tabs. But after switching to another > program that obscures the Firefox window, Firefox will redraw the window > after switching back to Firefox. I just updated to version 15 and the problem is still there but it is getting a bit better. If you do something and then close the window and reopen it, you can see what you have done. Still a problem that means I need to close the window entirely and restart Firefox but it is getting a bit closer. I don't understand why the developers don't consider this a major issue that needs to be fixed immediately.
I'm running on Nightly and have seen this problem many times. Came back home today after a couple of days where the computer was in sleep mode and found it to be basically unusable (while taking ~1.7GB of memory and ~25% CPU usage with only Facebook and Gmail open in the background) and I somehow managed to profile it using the Mozilla profiler :) Here is the link - http://people.mozilla.com/~bgirard/cleopatra/?report=c21ddbee183feb068295ba7d2538ffd29f20d5a4 Here is my about:support info: Application Basics Name Firefox Version 18.0a1 User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 Profile Folder Show Folder Enabled Plugins about:plugins Build Configuration about:buildconfig Crash Reports about:crashes Memory Use about:memory Extensions Name Version Enabled ID about:telemetry 0.14 true ping.telemetry@mozilla.com BetterPrivacy 1.68 true {d40f5e7b-d2cf-4856-b441-cc613eeffbe3} DownThemAll! 2.0.15 true {DDC359D1-844A-42a7-9AA1-88A850A938A8} Firebug 1.10.3 true firebug@software.joehewitt.com Ghostery 2.8.3 true firefox@ghostery.com HTML5 Notifications 1.0.8 true html5notifications@paxal.net SPDY indicator 2.1 true spdyindicator@chengsun.github.com Unseen 0.1 true unseen@tangrs Wallflower 1.4 true jid1-uB4sJEPvR2m4QQ@jetpack Cache Usage Statistics Collector 0.4 false cacheUsage@mozilla.todesschaf.org dontbeevil 1.1 false jid0-uKv2BxxWlXSDahl79DjVU4yqsvY@jetpack Flashblock 1.5.15.1 false {3d7eb24f-2740-49df-8937-200b1cc08f8a} Gecko Profiler 1.9.6 false jid0-edalmuivkozlouyij0lpdx548bc@jetpack MemChaser 0.4 false memchaser@quality.mozilla.org Suspend background tabs 1.0.1 false suspendbackgroundtabs@adblockplus.org Terms of Service; Didn’t Read 0.2 false jid0-3GUEt1r69sQNSrca5p8kx9Ezc3U@jetpack Test Pilot 1.2.2 false testpilot@labs.mozilla.com User Agent Switcher 0.7.3 false {e968fc70-8f95-4ab9-9e79-304de2a71ee1} Important Modified Preferences Name Value accessibility.typeaheadfind.flashBar 0 browser.cache.disk.capacity 1048576 browser.cache.disk.smart_size.first_run false browser.cache.disk.smart_size.use_old_max false browser.cache.disk.smart_size_cached_value 358400 browser.places.smartBookmarksVersion 4 browser.startup.homepage_override.buildID 20120927030539 browser.startup.homepage_override.mstone 18.0a1 browser.tabs.warnOnClose false dom.indexedDB.enabled false dom.max_script_run_time 0 dom.mozApps.runUpdate false dom.mozApps.used true extensions.lastAppVersion 18.0a1 font.internaluseonly.changed false gfx.direct3d.prefer_10_1 false network.cookie.prefsMigrated true network.security.ports.banned 8118,8123,9050,9051 network.websocket.enabled false places.database.lastMaintenance 1348781209 places.history.expiration.transient_current_max_pages 101813 plugins.click_to_play true privacy.donottrackheader.enabled true privacy.sanitize.migrateFx3Prefs true security.warn_viewing_mixed false webgl.force-enabled true Graphics Adapter Description Intel(R) HD Graphics Adapter Description (GPU #2) NVIDIA GeForce 310M Adapter Drivers igdumd64 igd10umd64 igdumdx32 igd10umd32 Adapter Drivers (GPU #2) nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM Unknown Adapter RAM (GPU #2) 1024 Device ID 0x0046 Device ID (GPU #2) 0x0a70 Direct2D Enabled true DirectWrite Enabled true (6.1.7601.17789) Driver Date 4-10-2011 Driver Date (GPU #2) 5-15-2012 Driver Version 8.15.10.2361 Driver Version (GPU #2) 8.17.13.142 GPU #2 Active false GPU Accelerated Windows 1/1 Direct3D 10 Vendor ID 0x8086 Vendor ID (GPU #2) 0x10de WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.1267) AzureCanvasBackend direct2d AzureContentBackend direct2d AzureFallbackCanvasBackend cairo JavaScript Incremental GC true Accessibility Activated false Prevent Accessibility 0 Library Versions Expected minimum version Version in use NSPR 4.9.2 4.9.2 NSS 3.13.6.0 Basic ECC 3.13.6.0 Basic ECC NSSSMIME 3.13.6.0 Basic ECC 3.13.6.0 Basic ECC NSSSSL 3.13.6.0 Basic ECC 3.13.6.0 Basic ECC NSSUTIL 3.13.6.0 3.13.6.0 Let me know if you need any more info...
Oops, didn't notice there are no developers here :) The stack seems to show GC as the culprit, does anyone know who to add to the CC list? or maybe how to triage the bug to javascript (it's greyed out for me)?
For those experiencing this problem (I'm not so can't debug it for you) here's what you should do: 1. Install Microsoft WinDbg: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx 2. Follow these instructions to run Firefox in WinDbg: https://developer.mozilla.org/en-US/docs/How_to_get_a_stacktrace_with_WinDbg 3. Let your computer go to sleep 4. After you wake your computer from sleep, see if it's hung. If it is, follow the instructions for getting a stacktrace "After the crash or hang" 5. Post your log here
(In reply to IU from comment #15) > 5. Post your log here I mean attach your log. Please do not post it as a comment. :-)
IU- I'll try and get a stacktrace with windbg (had problems with it and just realized I was running the 64bit version from the SDK) but can't the profile I gave help in any way? I know nothing of the Mozilla code base and even I know that 82% of the time spent in js:GCSlice is no good... does it not have enough info? In any case, I'll try and get windbg working :)
I can't get windbg to play nicely with firefox... Whatever I do it hangs right on startup (even after disabling all addons), the only way it doesn't is when I start it in safe mode (via passing -safe-mode to the program's arguments). Could this be a new issue with the nightly?
(In reply to Barak Gross from comment #18) > Whatever I do it hangs right on startup (even after disabling all addons), > the only way it doesn't is when I start it in safe mode (via passing > -safe-mode to the program's arguments). > Could this be a new issue with the nightly? windbg doesn't affect firefox. so if it doesn't hang on startup without windbg then something else is happening. Like an assert on startup. You can probably ignore most or all asserts and give a "g" in windbg, to just go past them.
(In reply to Wayne Mery (:wsmwk) from comment #19) > (In reply to Barak Gross from comment #18) > > Whatever I do it hangs right on startup (even after disabling all addons), > > the only way it doesn't is when I start it in safe mode (via passing > > -safe-mode to the program's arguments). > > Could this be a new issue with the nightly? > > windbg doesn't affect firefox. so if it doesn't hang on startup without > windbg then something else is happening. Like an assert on startup. You can > probably ignore most or all asserts and give a "g" in windbg, to just go > past them. I can't press 'g' in windbg because firefox doesn't crash, windbg says 'debugee is running' but the main firefox window is just hung while taking no cpu usage... If you'd like I can break on it while it's hung and follow the instructions above to get a stack trace...
(In reply to Barak Gross from comment #20) > I can't press 'g' in windbg because firefox doesn't crash, windbg says > 'debugee is running' but the main firefox window is just hung while taking > no cpu usage... > If you'd like I can break on it while it's hung and follow the instructions > above to get a stack trace... The document I linked states: "If Firefox hangs and there is no command prompt available in the debugger, open the Debug menu and choose Break." So, you first press 'g' to make sure that it's not just a debugger break waiting for your response. If you press 'g' and the Firefox is still hung, per the line I quoted above, you break and follow the instructions under the heading "After the crash or hang".
Attachment #666284 - Attachment description: Stack trace when firefox is hung under windbg → Stack trace after firefox is run with windbg
(In reply to Barak Gross from comment #22) > Created attachment 666284 [details] > Stack trace after firefox is run with windbg From the stack trace, I notice you have some extensions (for instance, ghostery). Have you tried with extensions disabled?
(In reply to IU from comment #23) > (In reply to Barak Gross from comment #22) > > Created attachment 666284 [details] > > Stack trace after firefox is run with windbg > > From the stack trace, I notice you have some extensions (for instance, > ghostery). Have you tried with extensions disabled? Yes, like I wrote above- "(even after disabling all addons)"... Having said that, I just tried playing with the addons again and it's now working- weird... :) So forget about that log and I'll get you a stack trace the next time the problem happens...
Attachment #666284 - Attachment is obsolete: true
I can't get firefox to run with windbg in a consistent way (one time it works, the other time it doesn't), and this is with no addons! IU- like I said, I'll try and get a stack trace soon (once firefox plays well with windbg) but you still haven't answered my question- is the profile I posted (not the attached file but the Mozilla profile URL) not helpful?
(In reply to Barak Gross from comment #25) > is the profile > I posted (not the attached file but the Mozilla profile URL) not helpful? I'm not actually a dev -- just a lurker. :-) What do you mean by "in a consistent way?" What is it not doing? Note that, if you WinDbg breaks debug, this is normal and happens anytime some external module needs to be loaded. Just press F5 (which issues the 'g' command) to continue debugging.
(In reply to IU from comment #26) > (In reply to Barak Gross from comment #25) > > is the profile > > I posted (not the attached file but the Mozilla profile URL) not helpful? > > I'm not actually a dev -- just a lurker. :-) > > What do you mean by "in a consistent way?" What is it not doing? Note > that, if you WinDbg breaks debug, this is normal and happens anytime some > external module needs to be loaded. Just press F5 (which issues the 'g' > command) to continue debugging. By "in a consistent way" I mean sometimes firefox freezes just like I described in comment 20 (where firefox is 'running' and is just hung and not responding and windbg did not break for debug) and sometimes it starts up perfectly (the previous attachment is after I manually broke like the URL describes so it should point to the same intermittent problem I'm seeing). Like I said, I'll try and get a stack trace with windbg but what's the point? if no one's looking at what I already posted who would look at the stack trace when I do get one?
I just upgraded to version 16 and the problem has gone away. Thanks.
(In reply to steve from comment #28) > I just upgraded to version 16 and the problem has gone away. Thanks. Sorry, I spoke too soon. It still hangs from hibernation.
Based on comment 10, it appears this issue exists post Firefox 11. If any of you having this problem is ambitious, a good bet would be to bisect nightly builds between Firefox 11 and Firefox 12 until you find the build that first introduced the bug. The build dates would thus be between March 13, 2012 and April 24, 2012; thus, not a huge number of build to test (especially if bisecting) You can find those mozilla-aurora builds at these two URLs: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/04/ That would help narrow things down dramatically.
On second thought, that range I provided will not work as the bug may have been introduced much earlier, so you would have to use a mozilla-central nightly build. you will actually need to bisect nightly (mozilla-central) builds from December 24, 2011 to April 24, 2012.
Hi everyone, great someone is actually looking into this. I have experienced the same behaviour for about a year now on my Windows XP x64 system. Running the nightlies, I managed to bracket it in to the following dates. Unfortunately, Firefox does not run at all on my system for a certain interval of snapshots. So the bug is likely introduced somewhere between December 9 and December 15, 2011. Any of the developers can check the ChangeLogs for this period to see what the major alterations to the code base were at this time? How could I do this myself?! Best wishes, Oliver --- 9.0 (2011-09-12) working 10.0 (2011-10-08) working 11.0 (2011-12-03) working 11.0 (2011-12-06) working 11.0 (2011-12-07) working 11.0 (2011-12-08) working 11.0 (2011-12-09) does not execute 11.0 (2011-12-10) does not execute 11.0 (2011-12-11) does not execute 11.0 (2011-12-12) does not execute 11.0 (2011-12-13) does not execute 11.0 (2011-12-14) does not execute 11.0 (2011-12-15) n/w after hibernate 11.0 (2011-12-17) n/w after hibernate 12.0 (2012-01-01) n/w after hibernate 13.0 (2012-02-02) n/w after hibernate
Browsing through http://hg.mozilla.org/mozilla-central/rev/63bff373cb94 'TimeStamp_windows.cpp' might be a candidate since it deals with timer issues after system wake-up. Wild guess however, as I'm not a developer.
(In reply to Oliver from comment #32) > Running the nightlies, I managed to bracket > it in to the following dates. Unfortunately, > Firefox does not run at all on my system for > a certain interval of snapshots. > > So the bug is likely introduced somewhere > between December 9 and December 15, 2011. Could you please try the "mozilla-inbound" builds from December 7 to December 14, to see if that makes any difference. If it still fails to run, try switching from the installer build to the zip build, or vise versa; and uninstall/delete the previous firefox program files first.
(In reply to IU from comment #34) I now ran the "mozilla-inbound" builds, i.e. firefox-11.0a1.en-US.win64-x86_64.zip and got the following regression: 2011-12-07 working normally 2011-12-08 working normally 2011-12-09 unresponsive after resume from sleep
Thanks, Oliver. Could you please try one more test. Please test with a recent Aurora nightly build to see is the problem still exists. So far I suspect that you may be right and that it was caused by bug 676349. However, don't add blocking until you've confirmed that the bug still exist in a current nightly. Thanks.
(In reply to IU from comment #36) Just tested today's (2012-10-30) nightlies of firefox-18.0a2.en-US.win32.installer.exe firefox-19.0a1.en-US.win32.installer.exe and they both still show the bug.
(In reply to steve from comment #5) > I do think you have the problem pegged. If I wait long enough before trying > to use Firefox after waking from sleep, it does come back to life. I can confirm this behaviour. If after resume you wait long enough before using it, it works normally.
(In reply to Oliver from comment #38) > (In reply to steve from comment #5) > > I do think you have the problem pegged. If I wait long enough before trying > > to use Firefox after waking from sleep, it does come back to life. > > I can confirm this behaviour. If after resume you wait long enough before > using it, it works normally. How long is long enough?
By the way, could you also provide the URL you were on when you were able to reproduce this.
(In reply to IU from comment #40) > By the way, could you also provide the URL you were on when you were able to > reproduce this. No particular URL opened. Just the Firefox startpage. (In reply to IU from comment #39) > (In reply to Oliver from comment #38) > > I can confirm this behaviour. If after resume you wait long enough before > > using it, it works normally. > > How long is long enough? Hard to say. The time it takes to prepare a coffee. In any case long enough to be annoying. Since we seem to have pinned the date it first appeared, is there a way to patch the suspected module with an earlier version and try if it changes anything?
(In reply to Oliver from comment #41) > Since we seem to have pinned the date it first appeared, is there a way to > patch the suspected module with an earlier version and try if it changes > anything? I've never made such builds before. Nonetheless, I'm CC'ing Honza, who worked on the responsible patch, and adding blocking so someone more skilled than I can take a deeper look.
Blocks: 676349
Component: Untriaged → XPCOM
Keywords: hang
Product: Firefox → Core
Whiteboard: [testday-20120615] → [testday-20120615] see comments 35, 37, 38, 41
I'm leaving this as unconfirmed, because I cannot personally reproduce. If someone else with confirming powers is able to reproduce, they can change it to NEW.
(In reply to Oliver from comment #35) > (In reply to IU from comment #34) > > I now ran the "mozilla-inbound" builds, > i.e. firefox-11.0a1.en-US.win64-x86_64.zip > and got the following regression: > > 2011-12-07 working normally > 2011-12-08 working normally > 2011-12-09 unresponsive after resume from sleep can you duplicate this finding, in safe mode, 32bit builds?
Flags: needinfo?(gfejer)
Keywords: regression
(In reply to Wayne Mery (:wsmwk) from comment #44) > can you duplicate this finding, in safe mode, 32bit builds? This may not be possible with mozilla-inbound for 2011-12-09 because it is missing the win32 build. @Oliver: The builds you indicated, in comment 32, would not execute, were those 64-bit builds? If so could you please try 32-bit mozilla-central builds. @Wayne: It still would be a good idea for someone to create a build with the bug 676349 patch removed.
Here are win32 and win64 builds with the original timestamp implementation (bug 676349 and followups effectively removed). Please try them. http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni.cz-010c22886173/
(In reply to Honza Bambas (:mayhemer) from comment #46) > Here are win32 and win64 builds with the original timestamp implementation > (bug 676349 and followups effectively removed). Please try them. > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni. > cz-010c22886173/ Hi, I installed this nighty version, and the bug is gone. I did experience this bug for a long time, I'm so glad it can be fixed.
Flags: needinfo?(gfejer)
(In reply to Honza Bambas (:mayhemer) from comment #46) > Here are win32 and win64 builds with the original timestamp implementation > (bug 676349 and followups effectively removed). Please try them. > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni. > cz-010c22886173/ Hi, thanks a lot for looking into this! The patch removes the issue for me too, so I'd be delighted if this could be fixed. What's the improvement in the new timer implementation that created the issue?
Confirming, because I just experienced this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(fehe)
Keywords: stackwanted
I'm not the right person to request a stack trace from. I've been able to reproduce this only once and haven't reproduced it since. Others, who are able to reliably reproduce, are better candidates for getting a stack trace.
Flags: needinfo?(fehe) needinfo?(fehe) → needinfo-
UI, was your hang with 64bit build, or 32? > I'm not the right person to request a stack trace from. I've been able to > reproduce this only once and haven't reproduced it since. you might have obtained stacktrace on a single occurrence per your instructions comment 15.
(In reply to Wayne Mery (:wsmwk) from comment #51) > UI, was your hang with 64bit build, or 32? 32-bit > you might have obtained stacktrace on a single occurrence per your > instructions comment 15. For about a year now, my computer goes to sleep every night and also every 2 hours of inactivity and yet I encountered the bug only the one time, so it's doubtful I'll be able to get the stack trace.
Status: NEW → UNCONFIRMED
Ever confirmed: false
What the heck. Bugzilla strikes again!
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to IU from comment #52) > (In reply to Wayne Mery (:wsmwk) from comment #51) > > UI, was your hang with 64bit build, or 32? > > 32-bit isn't most everyone able to easily reproduce this? In which case, I'd think UI's issue is different from what others are seeing. > > you might have obtained stacktrace on a single occurrence per your > > instructions comment 15. > > For about a year now, my computer goes to sleep every night and also every 2 > hours of inactivity and yet I encountered the bug only the one time, so it's > doubtful I'll be able to get the stack trace. apparently I didn't explain enough - which is that windbg need not be running when you hang for you to get the stacktrace. You can start with just a hung Firefox 1. firefox hang 2. start windbg 3. attach windbg to firefox process 4. obtain stacktrace
Attached windbg to firefox after resume from hibernate. I assume firefox still hang when I did this, cannot say for sure, though. First time I did a stack trace, so feedback welcome.
Comment on attachment 680467 [details] Stack Trace for Aurora 18.0a2 BuildID=20121030042010 Sorry, there is apparently no deadlock on the main (UI) thread, the stack looks pretty sane: 002dd210 02ade951 USER32!NtUserWaitMessage+0x15 002dd238 02929e10 xul!nsBaseAppShell::OnProcessNextEvent(class nsIThreadInternal * thr = <Memory access error>, bool mayWait = <Memory access error>, unsigned int recursionDepth = <Memory access error>)+0x151 [e:\builds\moz2_slave\m-aurora-w32-ntly\build\widget\xpwidgets\nsbaseappshell.cpp @ 298] 002dd2b0 02a818bb xul!nsThread::ProcessNextEvent(bool mayWait = <Memory access error>, bool * result = <Memory access error>)+0xb0 [e:\builds\moz2_slave\m-aurora-w32-ntly\build\xpcom\threads\nsthread.cpp @ 596] 002dd2e4 02a8fdde xul!mozilla::ipc::MessagePump::Run(class base::MessagePump::Delegate * aDelegate = 0x00000001)+0xcb [e:\builds\moz2_slave\m-aurora-w32-ntly\build\ipc\glue\messagepump.cpp @ 118] 002dd31c 02a8fd86 xul!MessageLoop::RunHandler(void)+0x21 [e:\builds\moz2_slave\m-aurora-w32-ntly\build\ipc\chromium\src\base\message_loop.cc @ 209] 002dd338 028155b5 xul!MessageLoop::Run(void)+0x15 [e:\builds\moz2_slave\m-aurora-w32-ntly\build\ipc\chromium\src\base\message_loop.cc @ 183] 002dd344 02a8fd06 xul!nsBaseAppShell::Run(void)+0x34 [e:\builds\moz2_slave\m-aurora-w32-ntly\build\widget\xpwidgets\nsbaseappshell.cpp @ 165] 002df298 02aba87c xul!nsAppShell::Run(void)+0x4e [e:\builds\moz2_slave\m-aurora-w32-ntly\build\widget\windows\nsappshell.cpp @ 232] 002df2a4 02885553 xul!nsAppStartup::Run(void)+0x1e [e:\builds\moz2_slave\m-aurora-w32-ntly\build\toolkit\components\startup\nsappstartup.cpp @ 291] 002df370 0282bfe1 xul!XREMain::XRE_mainRun(void)+0x405 [e:\builds\moz2_slave\m-aurora-w32-ntly\build\toolkit\xre\nsapprunner.cpp @ 3794]
Maybe the timer for the refresh driver doesn't get restarted properly after resume? That could make it seem like Firefox had hung.
Actually what I experience is that, after resume from standby or hibernation, the UI would not redraw when firefox remains focused. Once firefox losts its focus, the UI gets redrawed in the background. I think it is more like the description in bug 788171(Comment 16). Maybe a duplicate report? Anyway, since the UI did gets redraw(although at wrong time), it's possible that the problem is not due to deadlock. FYI, I did install the build you offered, http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni.cz-010c22886173/ and the problem goes away. (In reply to Honza Bambas (:mayhemer) from comment #56) > Comment on attachment 680467 [details] > Stack Trace for Aurora 18.0a2 BuildID=20121030042010 > > Sorry, there is apparently no deadlock on the main (UI) thread, the stack > looks pretty sane: >
(In reply to Rong from comment #58) > Actually what I experience is that, after resume from standby or > hibernation, the UI would not redraw when firefox remains focused. Once > firefox losts its focus, the UI gets redrawed in the background. I think it > is more like the description in bug 788171(Comment 16). Maybe a duplicate > report? > Anyway, since the UI did gets redraw(although at wrong time), it's possible > that the problem is not due to deadlock. Yeah, what you describe sounds like the refresh driver timer not getting restarted. And bug 676349, comment 68 seems to indicate how this is failing.
(In reply to Timothy Nikkel (:tn) from comment #59) > Yeah, what you describe sounds like the refresh driver timer not getting > restarted. > > And bug 676349, comment 68 seems to indicate how this is failing. Timothy, could you please be a bit more specific here? It sounds like we are targeting the code that needs to be fixed here. Thanks.
Flags: needinfo?(tnikkel)
(In reply to Honza Bambas (:mayhemer) from comment #60) > (In reply to Timothy Nikkel (:tn) from comment #59) > > Yeah, what you describe sounds like the refresh driver timer not getting > > restarted. > > > > And bug 676349, comment 68 seems to indicate how this is failing. > > Timothy, could you please be a bit more specific here? It sounds like we > are targeting the code that needs to be fixed here. > > Thanks. The refresh driver is responsible for driving painting, it lives at http://mxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.h and it uses time stamps. If time stamps somehow got screwed up it might screw up the refresh driver. I wanted to point out bug 676349, comment 68 here as at the time it looked like it was the best insight into this problem that we had. I don't have any better info.
Flags: needinfo?(tnikkel)
I'm also seeing this (on WinXP with Asus EeePC 1000H). And when it happens, I'm seeing it with FF and Thunderbird at the same time. I guess both share the same timer implementation? This would explain why they either both fail after hibernation, or they both don't fail. I believe bug 746345 and bug 788171 also refer to the same issue.
(In reply to Timothy Nikkel (:tn) from comment #61) > The refresh driver is responsible for driving painting, it lives at > http://mxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.h > and it uses time stamps. If time stamps somehow got screwed up it might > screw up the refresh driver. > > I wanted to point out bug 676349, comment 68 here as at the time it looked > like it was the best insight into this problem that we had. I don't have any > better info. Thanks Timothy, I also got some interesting feedback from Rong in bug 676349. I'll look at this soon.
Finally getting to this. I think I know what is the cause, thanks again for leading me to the refresh driver. After the wake-up TimeStamp::Now() returns GetTickCount() + sSkew where sSkew is way too old. We recalibrate because of waking up and TimeStamp::Now() now uses value of QueryPerformanceCounter(). Since sSkew is very old, difference between GetTickCount() + sSkew-before-recalibrate and QueryPerformanceCounter() is deep. I presume that we make a big jump back. But since there is a sentinel code that disallows TimeStamp::Now() going back, we for a long time return the same value - the last value of GetTickCount() + sSkew just before recalibration. This makes the refresh driver think the time has stopped. Solution here really is to disallow force of recalibration when flaw in QPC has been detected a longer time ago, say 10 seconds, but not when detected right after waking up. I'll crate a patch for it.
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Attached patch v1 (obsolete) — — Splinter Review
- when we've detected QPC failure sooner then right after wake up, we forbid wake-up recalibration to prevent Now() become crazy
Attachment #692483 - Flags: review?(ehsan)
Attachment #692483 - Flags: review?(ehsan) → review+
Anybody who is experiencing this bug, please test this build (will be ready in few hours after this post): http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni.cz-9d74f213d4e8
(In reply to Honza Bambas (:mayhemer) from comment #66) > Anybody who is experiencing this bug, please test this build (will be ready > in few hours after this post): > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni. > cz-9d74f213d4e8 Just tried "firefox-20.0a1.en-US.win64-x86_64.zip" (from the above link) on my Win XP x64. Unfortunately, the problem persists. = / (In reply to Maarten Deen from comment #11) > No response from Firefox when changing tabs. But after switching to another > program that obscures the Firefox window, Firefox will redraw the window > after switching back to Firefox. I can confirm this behaviour too. Hadn't noticed this before.
> Just tried "firefox-20.0a1.en-US.win64-x86_64.zip" (from the above link) on > my Win XP x64. Unfortunately, the problem persists. = / > I'm not sure about the x64 version, but the win32 version fixes the timer problem. Meanwhile, I've created binary patched dll files for the released version of firefox using ollydbg. It can be a temporary solution if you want to stick to the release branch: https://docs.google.com/folder/d/0B6YIFQYTjQuTeHZaZWtHbWozT2s/edit
(In reply to Oliver from comment #67) > Just tried "firefox-20.0a1.en-US.win64-x86_64.zip" (from the above link) on > my Win XP x64. Unfortunately, the problem persists. = / Oliver, can you confirm that the win32 build fixes the problem?
(In reply to IU from comment #69) > (In reply to Oliver from comment #67) > > Just tried "firefox-20.0a1.en-US.win64-x86_64.zip" (from the above link) on > > my Win XP x64. Unfortunately, the problem persists. = / > > Oliver, can you confirm that the win32 build fixes the problem? The win32 build doesn't work for me, either.
I'm running the above "firefox-20.0a1.en-US.win32.zip" on WinXP (Asus EeePC 1000H) for 1,5 days now, haven't seen the issue again. Right now, as a test, I did 10 hibernation cycles: every single cycle triggered the issue with Thunderbird 17.0 (which suffers from the same issue), but none affected FF-20.0a1 running on the same machine. Before the patch, when the issue occurred, FF and TB both used to be affected at the same time. So for me the issue indeed seems to be fixed. Thank you! :-)
Oliver, can you please run the test build of firefox with following environment variables set? NSPR_LOG_MODULES=TimeStampWindows:5 NSPR_LOG_FILE=c:\path\of\your\choice\to\logfile.log Please reproduce and then attach the logfile.log. It may help to understand. Maybe there are two issues here. Thank you!
Attached file NSPR TimeStampWindows —
Logging output for NSPR_LOG_MODULES=TimeStampWindows:5
(In reply to Honza Bambas (:mayhemer) from comment #72) > Oliver, can you please run the test build of firefox with following > environment variables set? > > NSPR_LOG_MODULES=TimeStampWindows:5 > NSPR_LOG_FILE=c:\path\of\your\choice\to\logfile.log Just did this with the x64 version. Started Firefox, opened a few tabs and then put the system into hibernate. When back from resume, I changed tabs and clicked on a link. Firefox would refresh after "Alt-Tab" to a different window (text editor) and back. Hope this helps. There is one ":(" in the output, so fingers crossed.
Attached patch v2 — — Splinter Review
Oliver, thanks a lot for the log! I think I know what other issue you are experiencing. This patch could be a solution. Please try this new test build: http://ftp-scl3.mozilla.com/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni.cz-ebe66b6edf95/ Thanks.
Attachment #692483 - Attachment is obsolete: true
(In reply to Honza Bambas (:mayhemer) from comment #75) > Created attachment 693203 [details] [diff] [review] > v2 > > Oliver, thanks a lot for the log! I think I know what other issue you are > experiencing. This patch could be a solution. > > Please try this new test build: > http://ftp-scl3.mozilla.com/pub/mozilla.org/firefox/try-builds/honzab. > moz@firemni.cz-ebe66b6edf95/ > > Thanks. Hey Honza, great job! This patch fixes the issue for me. Thanks for your persistence in looking into this.
Comment on attachment 693203 [details] [diff] [review] v2 - the same as v1 except the wake up retry acceptance interval shortened to 2 seconds only since I don't believe we will be getting on-wakeup notification later after waking up then in such short time - introduced "wake up adjust" to compensate difference between GTC + skew determined before sleep and QPC after waking up (see bug 822490 for explanation)
Attachment #693203 - Flags: review?(ehsan)
(In reply to Oliver from comment #76) > Hey Honza, great job! This patch fixes the issue for me. > Thanks for your persistence in looking into this. Thanks for confirming this, Oliver!
Blocks: 746345
Attachment #693203 - Flags: review?(ehsan) → review+
Since this is potentially dangerous patch and we have just 2 weeks to the next release and it's christmas time, I'll land this after the new year.
Or land now and back out from aurora when the uplift happens. Will give you even more testing.
https://hg.mozilla.org/mozilla-central/rev/ec5b0408864f
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
I wrestled with this same problem for weeks. Then it went away when I turned off "Allow Hybrid Sleep"
Though I don't have "Allow Hybrid Sleep" enabled, on my laptop, it hibernates after 360mins. Issue not seen if the laptop is resumed after a sleep, but only after resuming from hibernation.
This bug is marked as FIXED. If you still see bugs, please create a new one with clear STR and link your bug to this one.
Just some info to all involved in this bug: I recently checked-in a big change to the code that originally caused this bug. If anyone originally having this issue here (fixed by this bug) could please check I haven't regressed this bug again, use http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ to test with. Thanks.
(In reply to Honza Bambas (:mayhemer) from comment #86) > Just some info to all involved in this bug: I recently checked-in a big > change to the code that originally caused this bug. > > If anyone originally having this issue here (fixed by this bug) could please > check I haven't regressed this bug again, use > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla- > central/ to test with. > > Thanks. Just checked 'firefox-21.0a1.en-US.win64-x86_64.zip' and did not observe any unusual behaviour after resume from hibernate with this build.
(In reply to Oliver from comment #87) > Just checked 'firefox-21.0a1.en-US.win64-x86_64.zip' and did not observe any > unusual behaviour after resume from hibernate with this build. Thanks Oliver. Also, can I ask you for info what hardware you use? I'm quite interested. Feel free to send privately to my bugzilla email if you don't want to publish that info. Thanks.
Can also confirm it's also working with latest FF21 nightly. Hardware is Asus EeePC 1000H. The reporters in the related TB bug report either owned a EeePC 1000H or 1000HE.
(In reply to Honza Bambas (:mayhemer) from comment #88) > Also, can I ask you for info what hardware you use? Sure. Custom-built PC based on ASUS P5B plus http://www.asus.com/Motherboard/P5BPlus/ CPU is an Intel Core2 Quad Q6600 @2.4GHz 4GB RAM of which I only use 3GB b/c Win XP hibernate wouldn't work with 64-bit memory extension
I am having this problem with Firefox version 21.0. If I have firefox open and I close my laptop, then open it back up, Firefox fails to "wake up". The window just sits there completely unresponsive. I have to force quit the application and restart it every time I wake up my computer. I am not sure why this bug is marked as "RESOLVED FIXED" when clearly the problem has not yet been resolved... I am running Windows 7 64-bit on a dual-core AMD Athlon P320 with 4GB DDR3 RAM
(In reply to Dave from comment #91) > I am having this problem with Firefox version 21.0. If I have firefox open > and I close my laptop, then open it back up, Firefox fails to "wake up". The > window just sits there completely unresponsive. I have to force quit the > application and restart it every time I wake up my computer. I am not sure > why this bug is marked as "RESOLVED FIXED" when clearly the problem has not > yet been resolved... > > I am running Windows 7 64-bit on a dual-core AMD Athlon P320 with 4GB DDR3 > RAM I also forgot to mention that I did not start having this problem until upgrading Firefox. I was using a very old version before and I did not have this problem
This was marked fixed because one way this behavior can happen has been fixed. If you are still experiencing these issues, please file a new bug.
Point of information possibly related open bug 873110
See Also: → 788171
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: