Open Bug 629703 Opened 14 years ago Updated 2 years ago

big lags in responsiveness and hangs, then everything is ok in b11pre builds from Jan 27 and 27.

Categories

(Firefox :: General, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: chofmann, Unassigned)

Details

(Keywords: hang)

Attachments

(2 files)

I'm seeing the browser become completely unresponsive for 30-40 second stretches where I can't type in to url bar or forms on web pages, can't change tabs, or anything else I've tried. If I'm patient everything returns to normal. Right now seems pretty unpredictable about when this is occuring. I'll try and get some better monitoring hooked up to see what's going on and what the hangs might be connected too. Tomcat has seen this as well. So far observed on OS X 10.6; rv:2.0b11pre) Gecko/20110127 Firefox/4.0b11pre OS X 10.6; rv:2.0b11pre) Gecko/20110128 Firefox/4.0b11pre flipping a coin on firefox or core general.
activity monitor shows the CPU getting pegged durning the period of unresponsiveness. several windows with several tabs open, but nothing extreme. gmail, bugzilla, a bunch of my crash report .txt files, a few facebook and linked in pages. a few sites that are out of my normal browsing pattern that are open in tabs inlcude these: http://fosdem.org/2011/schedule/days http://l10n.mozilla.org/~stas/fx4special/ http://loombo.com/cjxdm81n0gdj http://netcourrier.com/
the interval between hangs is pretty large. maybe 15-30 minutes. still need to zero in on a better definition there. I'll try and post timestamps of when I see the next few instances.
I noticed one around 10:59 PST
again at 12:39 PST - but there was some time while the system was suspended moving between meetings. several minutes at hang. no system beach ball. Minefield is using 1.25 GBs real and 745 virtual memory, but only 4 or 8 GBs of total system memory is in use, so it doesn't sound like we might have waited for system memory to be filed before trying a big GC. will watch memory closer on the next one
It would be helpfuul if you could use Activity Monitor's "Sample Process" during the hang, and attach the output here.
one new twist. now the menu bar has gone completely unresponsive even though cpu is around 12% and switching tabs, scrolling, and typing in forms and location bar is still responsive.
do you have flash in any of those? I constantly see a hang similar to the one you describe when my plugin process crashes. And it crashes quite often :(
I haven't noticed flash running anywhere or any flash crashes. plugin process is ticking along run using 2.5% cpu and 58.8 MB real and 74 MB virtual memory.
I wonder if what I'm seeing is bug 617569. no crashes, but maybe that's because I have a lot of memory.
(In reply to comment #9) > do you have flash in any of those? I constantly see a hang similar to the one > you describe when my plugin process crashes. And it crashes quite often :( no flash video, but gmail which appears that it might have some embedded flash somewhere lately.
dolske, anything suspicious in the process logs, or anything other suggestions on how I could collect more info? The frequency seems to have gone down to 2 or 3 times per day, but its still happening?
yes, gmail uses flash when you have chat open (for the chat 'ping' sound ...)
coming out of one of the hang periods yesterday I got the dialog that an update was ready to install. maybe background downloads or or update checks were involved in at least that hang.
I had encountered this same behavior with FF5 and now even moreso with FF 6. This is on OS X. I always wondered if there was possibly an internal software conflict (Photoshop hangs too, on occasion); if I had to guess maybe Path Finder for OS X but I haven't tested this theory.
I was not able to reproduce this issue on FF 4.0 FF 5.0 and 18.b03 on Mac OS 10.8
(In reply to chris hofmann from comment #15) > coming out of one of the hang periods yesterday I got the dialog that an > update was ready to install. maybe background downloads or or update checks > were involved in at least that hang. Chris do you still see this?
Flags: needinfo?(chofmann)
not as much as when I filed the bug, but it comes and goes as a more severe problem every few releases. the length of the spinning beachball might have decreased as well. Haven't been able to pin it down on which content might be triggering, or what conditions might cause it. It usually takes quite a few windows with many tabs open in each to start seeing the problem.
Flags: needinfo?(chofmann)
(In reply to chris hofmann from comment #19) > It usually takes quite a > few windows with many tabs open in each to start seeing the problem. Current issue sounds like gc. But your initial report didn't require large numbers of tabs, correct?
> But your initial report didn't require large numbers of tabs, correct? yeah there were several windows and tabs, see comment 1; but I don't recall the exact numbers.
(In reply to chris hofmann from comment #0) > I'm seeing the browser become completely unresponsive for 30-40 second Can you still reproduce this issue on one of latest builds: Nightly, Aurora, Beta or FF 19 Release?
Flags: needinfo?(chofmann)
the length of unresponsive periods is a bit shorter, 10-15 seconds, but still see this on Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:20.0) Gecko/20130217 Firefox/20.0
Flags: needinfo?(chofmann)
(In reply to chris hofmann from comment #23) Thank you Chris! I'll invetigate this issue in one of this days.
Adding Anthony to QA Contact, maybe he can give us a helping hand because I'm a little confused about this issue.
QA Contact: anthony.s.hughes
chris, since you can reproduce this issue, can you please try to find the regression window for it? https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/
Flags: needinfo?(chofmann)
likelihood of finding a regression window or windows seems low. its also not completely reproducible, or reproducible within some kind of short time frame. combinations of tabs and windows with ajaxy apps like gmsil, https://mail.mozilla.com/zimbra/ , https://www.google.com/finance/portfolio with a long stock watch portfolio list, a few youtube window, many bugzills windows and tabs, occasional maps.google.com all might be working in parallel or independently to create the frequent beach ball condition. wish I had more of a test case, or some better tools to analyze when I see it. lately things have gotten worse again.
Flags: needinfo?(chofmann)
Agreed that a regression range is unlikely to be found at this point (or even be helpful if it was by some chance). Chris, is this still an issue for you?
Flags: needinfo?(chofmann)
yes, still comes and goes. mostly after a few days of many windows and tabs open, with the majority being gmail, google spreadsheets, google calendar with its new blocking alerts, the IRC addon running in a window with many channels going, and a few other complex web pages/apps, plus updates on the beta channel that I see appearing. it gets to the point where I need to kill Firefox and restart to have a usable browser again, but I know that I'm stressing the browser with all that I'm doing. Do we have any systematic stress tests that we need to extend to understand that kind of usage better, or do we need updates again as the web changes? my old browser buster changed to page load tests, then we had a round or two of updates to the content, but have we updated those tests lately? I wish we had a tool for understanding which windows/tabs might be the source of the slowdowns, and/or if its cumulative over many pages and things going on in the browser. I also couldn't get the latest flash update install to work after many attempts, so I've removed the npapi flash from my system, and it seems to have helped a bit, but its mostly just extending the time until I hit the beachball wall. Its ok to get rid of this bug, or may spin of into a few around the suggestions above on adding tools or creating/updating stress tests. That might be the only way to get a better handle on fixing what I see.n
Flags: needinfo?(chofmann)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: