Closed Bug 248345 Opened 19 years ago Closed 17 years ago

Temporary freezes of several seconds during normal usage at low cpu

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 223476

People

(Reporter: mkosmul, Unassigned)

Details

(Keywords: perf) 

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 (also Firefox 0.9 official build (gtk2+xft))

I have observed this behavior with official builds of 0.8 and 0.9 but I have
used a 0.8 version compiled from source for a while and it didn't show this
behavior.
When Firefox is used (0.8 and 0.9 official builds gtk2+xft), once in a while (at
least several times a day, sometimes a dozen or so times a day), the browser
window freezes and doesn't react to any input (e.g. button don't get highlighted
when the mouse moves over them etc). After a few seconds, everything is back to
normal, but this behavior is annoying. This tends to happen while a page is
loading and starts rendering, but also after a page is already loaded and I'm
just viewing it. While the window is frozen, there is no extra CPU usage
visible, nor is there any swapping from RAM to disk that causes this - the
machine doesn't seem to perform any extra activity. 

Reproducible: Sometimes
Steps to Reproduce:
Use the browser on a regular basis. It doesn't seem to be related to having the
firefox application running for a long time - sometimes the freeze happens right
after staring the application, sometimes one can use a single open window for
several hours and it doesn't freeze a single time.
I did experience such on SuSE Linux 9.1 Professional, but now that I'm on
Gentoo, I have not seen this in any build.

WFM
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040628 Firefox/0.8.0+
This is a bit vague, so this bug is going to be squashed soon as Invalid or
something like that, unless you can narrow it down. There's loads of issues that
could be causing this from memory leaks to other applications spiking in CPU
usage. I personally experience this on sites with Flash, Java, Shockwave, etc.
media, especially my older computer, since it takes a bit for the plugin handler
to load.
One thing's for sure: it doesn't show any dependance on CPU load or using any
plugins or anything one could typically suspect of being the cause for such
behavior. It has often happened when firefox was the only application open on an
otherwise idle system, with CPU usage equal to 0 within the error margin.
One possibility could be that I experienced those freezes while using Con
Kolivas' kernel patches, which are supposed to reduce latency and improve
responsiveness of the system for interactive use. I have now recompiled a
vanilla kernel and will have to see if the freezes are gone.
I have noticed this behaviour, too. It seems to have gone away when I upgraded
X.org from 6.7.0 to 6.8.0.
I have to cancel what I said. After upgrade to Xorg 6.8.0 the problem still
exists, but it occurs only if I leave system alone for a longer time (a few
hours or so).
Sounds like a memory leak. In which case, it joins the ranks of the many memory
leak bugs that Bugzilla currently holds.
could also be a dup of bug #235853, if you are using a proxy pac...

during load its easy to understand, if already loaded, could be a ad changing
script or a flash
try to see if there is any network traffic during the freeze (ie: dns queries)
or after the freeze, if yes, then its the DNS problem 
It's hard to reproduce this bug reliably and I can't capture packets 24/7 to
check if there are DNS queries being performed during the freezes. However, I
first reported this bug for Firefox 0.8 and now that I use 1.0PR, this problem
happens much less often. I also think it now only happens when a new page is
opened, so it could be DNS-related, indeed.
I have seen this on two debian installations (one is my own). It's a typical
freeze in that the ui gets frozen, no updates, no events etc. This will last
from less then a second to up to 5-6 seconds.

To me it seems it has something to do with typing/changing the url. It is very
random and I have not been able to pinpont a pattern.

I'm using FF1.0 debian build.
The lag happens on macos as well (showing the well-known "beach-ball of death"
after ~3 seconds), and can last up to ~30 secs, which is very annoying. It is
sporadic, but happens several times an hour. It does not seem to depend on the
site or site technology (it is definitely not java or flash).

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a6) Gecko/20050105
Firefox/1.0+
Darwin dhcp-253.xxxx.de 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov  7 16:06:51
PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC  Power Macintosh powerpc
To me it does not seem to be a dns problem. At least I had such a lag (there
could be more than one, of course) when there was no unanswered dns query in
tcpdump.
I'm seeing this behavior at work (FF1.0 on WinXP) and at home on Win2000Pro 
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1  

I have also seen it frequently on a Gentoo system with latest KDE, but the sysop
FUBARed the box, then went skiing, so I can't get details.  He claims it's
working perfectly on his Gentoo box, but he has an amazing tolerance for OSS
foibles. 

By running the Task Manager, I can see that the CPU usage goes to FF=100%
whenever there is a hangup in changing windows or tabs.  These hangups happen
almost every time I want to change windows or tabs or load a new page.  

I don't have lots of windows open, don't have wallpaper or slideshows ... it's
just FF being a cycle-sucking memory hog.  
I noticed this immediately when first using the package that comes bundled with 
the new Red Hat Enterprise Linux 4.0.  It's quite prominent and irritating, 
though I can't pinpoint a pattern.  Usually when I'm typing an address into the 
address bar.  It's definitely not subtle, and if you move a frozen window 
across the screen, it'll paint a smear as it goes.  Within 20 seconds or so, it 
usually unlocks.  It's prominent enough as to make me want to avoid using 
firefox completely.  We're not talking an eventual, rare, subtle freeze.  It's 
a big one, early and often.

I'm running a twin processor Xeon system, X86_64 (EM64T), and it's prominent.  
However I have NOT seen this problem at all on a single processor (but 
hyperthreaded) 32-bit system, which has an identical install (RHEL 4.0).  So, 
not sure if it's a dual processor problem or one related to x86_64.  
By the way, (addendum to comment immediately above) I use KDE 3.3.1 (as 
distributed with RHEL 4.0).
Happens here as well on an XP SP2 machine and FF 1.0.3. The original 
description is right on the money; freezes can occur when loading a page, but 
also when doing nothing at all.

The XP machine is spanking new, with no profiles or add-ons installed (of 
course).
(Sorry, forgot some info in previous comment.) FWIW, I see the exact same 
problem in K-meleon 0.9 and Nvu 1.0PR (20050330).
I sometimes observe the same behaviour when I open a new, empty tab.
So this is probably not a plugin oder DNS problem. 

Is this still being seen?

(Moving to General from Build Config [why was it there?])
Assignee: bryner → nobody
Component: Build Config → General
Keywords: hang
QA Contact: asa → general
Yes, Firefox 1.5 behaves in the same way.

By the way: I set up a new ~/.mozilla directory and am still observing the same behaviour.
perf issue, not hang  (the system comes back and responds)

anyone who suspects dual processor/multi processor/hyperthread as a cause should probably visit a bug already filed with that keyword rather than comment here.

likewise, cases that have high cpu are probably not related.

details from Michal and comment 9 (Mikko) and 10 (strattbo) of what was last done in the window might help along with any URL(s) currently on the window.

can it be recreated even if no page has been loaded? how about a local page loaded from the PC, not the net?  eg copy the pages that were open when you had trouble
Keywords: hang → perf
Summary: Temporary freezes of several seconds during normal usage → Temporary freezes of several seconds during normal usage at low cpu
everyone who reported ...

does this happen with a recent trunk build?  http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

non-hyperthread, non-multi cpu?

and for clarity, what cpu load and restate what specific action(s) instigates it (mouseover, typing URL, doing nothing, etc)
Wow, this is an OLD thread and I forgot all about it.  I found a solution for ME, some time ago, and have had no problem since.  Mine was related to the
KDE tool 'klipper.'  As soon as I turned klipper off, the freezes went away.  I haven't used klipper since, and have had no problems.  

I recently updated to Firefox 1.5.0.1 and it seems the exact problem described in my original report is gone. However, in the meantime I have also changed CPUs (AthlonXP when first reporting the bug, currently Athlon64).
Still, I now observe behavior similar to that described in the original bug report. What happens is exactly the same as previously: no response from the GUI and 100% CPU usage for several seconds. However, it doesn't happen during normal browsing any more. The action that triggers this behavior is the following:
* Open a new Firefox instance
* Open the Bookmarks menu
* Move the mouse pointer to the Go menu
* Wait several seconds until the menu opens and the GUI stays unresponsive
My bookmarks are not very many - perhaps 200 or 300 but not more. They are grouped into about 10 folders.
When I repeat the whole menu-opening process for the second time, there are no side-effects and menus open as fast as I expect them to.
Michal: what you describe doesnt seen like the same but, please submit a new bug (check for dupes also 8)

Michael, "Go" menu freezing things because of a large history file is discussed in bug 223476.
Status: NEW → ASSIGNED
Aleksey: Why did you mark this bug as ASSIGNED? Nobody is assigned to it.
Status: ASSIGNED → NEW
(In reply to comment #26)
> Aleksey: Why did you mark this bug as ASSIGNED? Nobody is assigned to it.
> 
Sorry, didn't do it intentionally - must have been a Bugzilla glitch or an accidental click in the wrong place :-(

(In reply to comment #27)
> (In reply to comment #26)
> > Aleksey: Why did you mark this bug as ASSIGNED? Nobody is assigned to it.
> > 
> Sorry, didn't do it intentionally - must have been a Bugzilla glitch or an
> accidental click in the wrong place :-(

No problem. Bugzilla brings out the worst in all of us. Sorry about seeming to "jump" on the issue. :)
Thanks for the hint to view bug #223476. It fits what I observe now very well. With my history kept for 360 days I seem to be a perfect candidate to become a victim of the problems mentioned there. Still, I would have never guessed opening the Go menu is slow because of my large history - this menu doesn't show any old history items, only current session, so this is quite surprising.
Anyway, I would mark current bug as WORKSFORME since it seems to be gone since I upgraded to 1.5 but there were some other changes in the meantime as well (processor change, X.org upgrade etc.) and some somments suggest this may still be present in 1.5. As for me, the problem seems to be gone. And I'm sure going to vote for #223476 to be fixed ;)
(In reply to comment #29)
> Thanks for the hint to view bug #223476. It fits what I observe now very well.
> With my history kept for 360 days I seem to be a perfect candidate to become a
> victim of the problems mentioned there.

Niklas, Henrik - Can you clarify your reports in light of recent comments?
I have switched computers since I reported this bug and the problem is not reproducable in my existing setup.
(In reply to comment #29)
> Thanks for the hint to view bug #223476. It fits what I observe now very well.
> With my history kept for 360 days I seem to be a perfect candidate ...
> Anyway, I would mark current bug as WORKSFORME since it seems to be gone since
> I upgraded to 1.5 but there were some other changes in the meantime as well
> (processor change, X.org upgrade etc.) and some somments suggest this may still
> be present in 1.5. 

Michal, 
You should close this as a dup of 223476.  If others still have problems, then it's not the one you reported and they shold look for another bug or file a new one.


OK, I'm marking this as a duplicate. I'm not quite sure whether it really is a dupe or if the original problem was another issue which is fixed now. If anyone experiences orignally reported problems again, we can reopen this report.

*** This bug has been marked as a duplicate of 223476 ***
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.