Closed
Bug 704894
Opened 13 years ago
Closed 12 years ago
Periodic ~30-second lock-up of all Firefox windows, restores itself but very annoying
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 572459
People
(Reporter: mozilla_bugzilla, Unassigned)
Details
(Keywords: hang, perf, Whiteboard: [Snappy])
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0 Build ID: 20111104165243 Steps to reproduce: I daily use Firefox since version 1.5, now using 8.0 (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0) from the release channel. If I remember correctly I installed Fx fresh on version 4 or 5, and have used the usual update mechanism since. I do not frequently install and remove addons, surely no addons where installed and remove for the last couple of months. How I browse, and how I browsed in this particular case as far as I remember: Usually I have multiple windows (not tabs) open at a time, with varying types of content. Many different news websites and blogs, YouTube, Google mail, Google docs, Facebook, some forums. When I'm done with a particular subject I just close the window, but things that I want to read later on will be kept open until I've come around to them. This may span more than 24 hours. This comes down to sometimes having up to (but usually no more than) 20 windows open at the same time. Sometimes as little as 3 or 4, and then up to 10+, etc. Firefox is kept open 24/7 if it doesn't crash or becomes more unresponsive than I can bear. Firefox uses a lot of memory after long times of browsing. That's not the main subject for this bug, but it's worth mentioning that this is also the case for me. This very recent attachment from bug #490122 displays the about:memory and about:support in a state where I was experiencing *this* particular bug. https://bugzilla.mozilla.org/attachment.cgi?id=576518&action=edit Actual results: Version 8.0 of Firefox locks up on me once in about every 1-2 hours, for about 15-30 seconds. The moment it locks up doesn't seem to related to anything I'm doing. It may happen when I'm just watching a movie, or when I'm typing a document. I even believe it happens when I'm just scrolling over a page, or even when I wasn't doing anything with Firefox and then decide I want to google something. It's hard to remember although I run into it quite frequently. Details: All Firefox windows stop responding to mouseclicks, keyboard, everything. Content stops moving/playing. The first few seconds windows still seem to respond to switching, but then suddenly also the interface freezes and the windows cannot be closed, minimized, etc. Windows 7 64-bit then indicates the -at that moment- current window is not responding. After perhaps 15-30 seconds, all windows start responding again and Firefox continues as if nothing strange has happened. When I'm watching a movie on YouTube, the video playback stops on the screen but the sound keeps on going for maybe another 20 seconds before it stops. When the window becomes responsive again, I've missed all video played during the lockup. Firefox automatically continues playing though. This has happened to me several times now, since I upgraded to 8.0. I do not remember having simular problems on 7. I have restarted Firefox many times to see if it would fix the lock ups but to no avail. In all cases, I close Firefox in responsive state and on restart it opens all sites I was using when I last closed it. It's worth noting that even with about 10 sites open, Firefox also becomes unresponsive for seconds and seconds when opening sites on startup. I'm not sure if it's related. It's also worth noting that I think a lot of people may not be so patient as I am, and decide to kill Firefox before it comes around to making itself respond again. This way of closing Firefox may not provide you any kind of automatic feedback, probably making it difficult to pin down using crashreports or anything. Expected results: The obvious response is that I expect Firefox to be responsive. I'm not even very picky, but lock ups of 15-30 seconds are a bit over the top, even for me ;-) I've experienced bug #490122 for almost a year, so I'm used to something. On a more serious note, broader than just this issue: To my experience a lot of Firefox versions over the last ~ two years have MORE and BIGGER issues than the versions of years before. The amount of add-ons I use is becoming smaller and smaller. But the problems I experience with Firefox have become bigger and/or more noticable. I very much hope this can be turned. I will do my best to help solve this anything else I find, but I just don't always have the time.
I have experienced this as well. Unfortunately it's another one of those symptoms which don't have reliable steps-to-reproduce, but I can certainly confirm the symptom. On Win7 Aero, the Firefox window is greyed out while this happens. The OS suggests that the program is not responding and offers to close it. I guess this means it isn't spinning the message loop properly, which indicates some long processing on the UI thread. Devs: please suggest ways in which we can provide more information about these hangs.
It seems that the pauses start out small compared to what I reported. I've been running Fx since yesterday ~13:00, currently it's 10:20 here, and I just experienced a 10-second lockup of all my windows. I wasn't even browsing the web for the majoraty of the hours during that time period! It's 21.5 hours, of which 8 hours I was asleep, and I estimate there are about 10 more hours where I was not using Fx. And if I was browsing, all I've done is some really basic stuff. Memory usage according to Task Manager is 420 MB now, I will attach about:memory next. It almost seems as if everything is fine, until I leave my Firefox idle for a longer period of time and then come back to actively use it again. Could this be triggering something strange?
Goes with comment #3, displays memory usage after about 21 hours of Firefox running with an estimated actual use (very basic browsing) of about 3-4 hours.
I was restoring my Firefox session (after a normal quit and a reboot a few minutes earlier) and Firefox was unresponsive while restoring, and then after less than 5 minutes of simple usage, it was unresponsive again for about 15 seconds. I will attach about:memory of right after that moment.
about:memory right after 15-second freeze, 5 or less minutes of Firefox usage. This was after restoring 9 windows on Firefox start, after a succesful quit earlier and a reboot of my Windows 7 machine.
I've had two such lock ups so far. Each time I rushed to suspend the process using Process Explorer, and take a peek at what it's doing. There are a number of threads, but the one that looks like the GUI thread (the only one in firefox.exe) was waiting for I/O as far as I could tell. So I suspect this is a particularly bad case of the general "doing synchronous I/O on the GUI thread" problem. They've fixed a few instances of this, but there are probably lots more.
Since last time I posted, I have upgraded from 4 GB of DDR2, to 8 GB of DDR3. The lockups as described have vanished, but I expect them to be there when I would take away 4 GB of my ram. The fact that upgrading memory helped solving the problem on my particular workstation doesn't say anything about other workstations of course.
|
||
Comment 9•12 years ago
|
||
Martijn - I note that your about:memory results (in addition to a 550MB google docs compartment) is ~2.8GB vsize. That's up near the limit for process size on Windows for a 32-bit process. In the past when nearing that limit I've seen windows lock the process for ever-longer periods while it does *something* with page tables, etc (signature is 100% of a core in the kernel the whole time - easiest to see with something like sysinternals "Process Explorer" (from Microsoft). Sysinternals will also show you what the process is doing when this happens (paging, memory use, etc) - double-click on the FF process. The other possibility is a leaking extension or bug in google docs. I suggest closing the google doc and see if the problem goes away (though if it's memory related that might solve it there). Also, go to Tools->Web Developer->Error Console, and watch the CC and GC results (set javascript.options.mem.log to true in about:config) and see if they spike at that time or if there's some other error message at that time this happens.
|
||
Comment 10•12 years ago
|
||
Firefox seems to be rather sensitive to busy HDDs; if *anything* does lots of IO (that includes paging due to low memory) then Firefox *will* block for significant amounts of time. I have observed this repeatedly, and this is reasonably reproduceable: start a couple of parallel file copies and a disk defrag on the drive containing the Firefox profile, and try to use Firefox. Firefox needs to hit the disk quite often, apparently, and thus ends up blocking for several seconds a time. I suspect the even longer pauses are caused by this too, possibly exacerbated by requiring several I/Os or Firefox having been paged out.
|
||
Comment 11•12 years ago
|
||
Martijn, Roman, have you tried Nightly builds? http://nightly.mozilla.org/ They should have some fixes which improve I/O handling. (Nightly builds have also lots of other fixes)
|
|
||
Comment 12•12 years ago
|
||
A main drive of the 'snappy' work has been to move IO off the main thread, so the browser remains responsive. That isn't to say there might be asynchronous waits for disk IO to complete before actions happen, even if the main thread isn't blocked. If something needs to (asynchronously) save data to a database, other actions may wait for that to complete before they can continue. Roman: can you try your busy-HDD test on a nightly? And then, if it still happens, can you disable the disk cache as a test? about:config - it's browser.disk.cache.enable. Thanks
|
||
Comment 13•12 years ago
|
||
Martijn ? Roman ?
|
Reporter | |
Comment 14•12 years ago
|
||
Sorry; completely forgot about this one. I'm not experiencing this on Fx 12 and 13. Looking back, I think the problem was there for about a week, maybe two, and then it must have went away. I'm only using the normal release channel, no nightlies. There was no clear solution to it I'm sure, otherwise I would definitely reported it here. On 13, I'm experiencing other issues that seem related to GC/CC which have been reported in a other bug on bugzilla. (for those who are interested: https://bugzilla.mozilla.org/show_bug.cgi?id=646941) I've also installed the MemChaser addon so I can easily see if GC/CC are a possible cause.
|
|
||
Comment 15•12 years ago
|
||
Testing Firefox 16 (2012-06-13). It's still quite easy to make Firefox stall under I/O load. I create a clean profile, open a few tabs (eBay, Google Maps, Wikipedia). Restart. I then run 5 instances of a program that does nothing but write data (generated on the fly) each to a separate file. They all write to the same disk that holds the Firefox profile. While running, I open the three websites via the History sidebar, and try to switch tabs using Ctrl+Tab while they are loading. I find Firefox unresponsive for 5-10 seconds at a time. During this time, other programs remain usable. I tried interacting with Skype, MediaMonkey, Notepad2 and FAR. Windows is not short on RAM; more than 3 GB (out of 8) physical RAM is reported free by ProcExp. This is a four-core machine and ProcExp reported 25% CPU load. Firefox profile is on a mechanical HDD. Setting "browser.cache.disk.enable" to false and restarting made no difference at all. I followed the same procedure with the I/O load off, and Firefox was reasonably responsive (though nowhere near silky smooth).
|
||
Updated•12 years ago
|
Whiteboard: [Snappy]
|
||
Comment 16•12 years ago
|
||
Yes, Firefox performs poorly due to pervasive main thread IO. We are working on getting rid of it.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•