Closed Bug 174473 (badXUL.mfl) Opened 22 years ago Closed 22 years ago

edit=>find.../ctrl+f/ctrl+g cause mozilla to freeze and CPU utilization shoots to 99% [corrupted XUL.mfl]

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 169777

People

(Reporter: justincwatt, Assigned: bugzilla)

References

Details

(Keywords: hang)

Attachments

(1 file)

screenshot showing freeze and CPU utilization
24.28 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910

Selecting Edit=>Find in this Page or Edit=>Find Again or Ctrl+F or Ctrl+G causes
Mozilla to freeze on any page and CPU utilization shoots to 99% and memory
usages steadily increases.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.




I have gestures installed.

Possibly similar to/duplicate of Bug 50766.
==> XP / GUI
Assignee: asa → blaker
Component: Browser-General → XP Apps: GUI Features
Keywords: hang
QA Contact: asa → paw
Now I'm not sure how reproducable this is. I've got the screenshot to prove it,
but Ctrl-F is working just fine now. And before it was freezing after restarting
Mozilla and restarting Windows 2000. Possibly intermittant, or some other
interaction.
I'm experiencing the same problem on my Windows 2000 machine. The browser
consistenly freezes and CPU usage skyrockets once I use ctrl+f or 
Edit->Find in This page. Even after a clean reboot with barely anything else
running I'm still getting this. I have another machine running XP Pro/SP1 that I
can't reproduce the problem on however.
Seeing this consistently (100%) under Windows XP, Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.2b) Gecko/20021015.  

Haven't seen this in previous builds, but I'd upgraded to this build straight
from 1.2a.

Also happens when I attempt find while viewiing source.
Correction - read "upgraded" as "completely uninstalled 1.2a, then installed the
nightly"
Notice the same problem on WinXP/SP1 with CPU usage going to 100%, and memory
increasing to atleast 70+Megs (killed it there, normal is around 30Megs).
Build ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016
Same problem on win2k with "Mozilla/5.0 (Windows; U; Windows NT 5.0; sk-SK;
rv:1.2b) Gecko/20021016"
See screenshots at http://www.volny.cz/laubrino/mozilla/
In addition to the CPU utilization spiking at near 100%, Mozilla also starts
consuming memory like a starving man at a buffet, when this bug occurs.  I
reproduced this (build 2002101612 on win2K) and then opened task manager, and
watched the mozilla.exe process go from using 30M of ram, to 50M+ in less than a
minute.
I am getting the same Find command freeze on Mac OS X (10.2.1) using nightly
2002102903. Mozilla's CPU usage on my Pismo (G3 400) goes to about 55% after the
freeze, instead of its usual 2-10%.

This did not happen in 20021022 nightly. I am downloading 20021101 now.

I can safely view source, and I do not have gestures installed.
Mac OS X nightly 2002110108 does not exhibit the Find freeze. Perhaps looking at
the diffs between 20021022 (no), 20021029 (yes), and 20021101 (no) will help
find clues?
Having just done a full upgrade to Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US;
rv:1.2b) Gecko/20021016, on an eMachines eTower 667ir running WinMe, seems to
have corrected the problem that I was having with regard to the hanging problem.

Steve
*** Bug 179813 has been marked as a duplicate of this bug. ***
I've also noticed that the main() thread is the one that freezes.  That is,
using PView, I've determined that thread 0 of the mozilla process (almost always
the main() entry point) is the one that's spiking the CPU.
Ok, I just rebooted and "Find" is working fine.  Note, quitting and re-running
mozilla would not fix this problem.  Only after a reboot.  This looks like it's
going to be maddening.
*** Bug 179687 has been marked as a duplicate of this bug. ***
I confirm this on Windows NT 4, so the OS windows 2000 is not good
Mozilla 1.3a Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021111
to those who see this bug:

Are any of you using other themes than classic or modern when the bug happens?

Using one of the default themes: If you delete the file XUL.mfl in your profile
directory before starting mozilla - Does it freeze then too?
about theme (comment #18):
I'm using modern theme but:
- radial context of optimoz
- moztweak
- I have other themes installed (but do not use them)
desinstalling optimoz radial context (1.0rc3) made the problem dissappear.
reinstalling it does not afterwards make the problem reappear. I've been using
radial context for a while without problem, but I installed moztweak very
recently, and then only I've add the hang problem.

I'll try more experiences and report the results soon.
as I don't know how to deinstall MozTweak, I reinstalled it (without
deinstalling it first). The hang has not reappeared yet.
MozTweak is part of mozillapl project ( http://mozillapl.mozdev.org/ ) but my
locale is english, not polish.
I'm running Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.3a) Gecko/20021123
and I've just encountered this bug. Freeze, memory consumption up to a little
above 100MB and then crash (by Mozilla itself, I didn't kill it and the OOM
killer didn't either as there was still RAM available). Restarting Mozilla
didn't help. Ctrl-F consistently crashed the browser. I then started up a
20021116 build and it worked fine. After switching back to 20021123 that one
worked fine again, too. So I guess it has to be something in the profile that
gets reset whenever a Mozilla build different from the previous is run.
I'm running Modern theme. Only tweak is preferences toolbar, but I have this
installed in the 20021116 build also.
Note, that this is on Linux, so the bug is not limited to Windows!
deleting XUL.mfasl as suggested in comment #18 fixed this for me.

I had moved from Mozilla 1.1 to 1.2 keeping the same profile and hit this
problem. As everyone else said, 100% reproducible hang with ctrl+f or Edit=>Find
on all pages. Moved XUL.mfasl out of my profile dir and now find works fine.

This is with Moz 1.2, classic theme, Linux 2.4.18.
I'm experiencing this bug as well; I'm using 1.2 with the default install under
Win98, and control-F always makes the computer freeze up until I kill Mozilla.
Confirmed on Mac Os X 10.2.2 with Mozilla/5.0 (Macintosh; U; PPC Mac OS X;
en-US; rv:1.2.1) Gecko/20021130

Restart doesn't help and neither does using a default skin as suggested in
Comment 18 as I do not have a XUL.mfl file in my profile directory that I can
delete.
This is happening for me as well.  It just seemed to start happening after
upgrading to 1.2.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20021130).

I'm using Mandrake 8.1 and KDE 3.0.  Modern theme.
I should have read all the comments before posting..SORRY!
Moved XUL.mfasl from profile folder and Find works properly now.
this bug shows up when searching for text in the 'View Source' window as recent
as mozilla 1.2

still appears to be intermittent.
*** Bug 174904 has been marked as a duplicate of this bug. ***
*** Bug 184876 has been marked as a duplicate of this bug. ***
Any relationship to Bug 185289 on Mac OS X?
I'm seeing the same with Mozilla 1.3a (Build ID: 2002121222) on Linux (RedHat 8).
*** Bug 185289 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 187162 has been marked as a duplicate of this bug. ***
Alias: badXUL.mfl
Summary: edit=>find.../ctrl+f/ctrl+g cause mozilla to freeze and CPU utilization shoots to 99% → edit=>find.../ctrl+f/ctrl+g cause mozilla to freeze and CPU utilization shoots to 99% [corrupted XUL.mfl]
I have encountered this problem as well. My system:

SuSE Linux 8.1 (kernel 2.4.19)
Mozilla version 1.3a
KDE 3.04

At first I thought that the problem might be related to the NVidia Video drivers
installed on my system, but then I saw all of the reports from others, so I tend
to discount the video driver as the reason.
Blocks: FastLoadMeta
As a previous user said, I should have read all of the postings. Renaming the
file  XUL.mfasl in my home directory (I'm running SuSE Linux 8.1) has solved my
problem. Actually, XUL.mfasl has been recreated in my home directory, but its
size is 985137 bytes, whereas the old XUL.mfasl is 3030008 bytes.
I quickly read some of the comments:

If the hang appears at some time, then becomes reproductible (allways, or nearly),
and is cured by deleting XUL.mfl / XUL.mfasl / XUL FastLoad File,

Then I suggest that you mark this bug as a duplicate of bug 169777,

or at least depends on it: This search feature seems to be a good/often test
case, like 'Edit > Preferences' for bug 169777.

Another meee tooo.  Win98, modern theme, 1.3a crawled into a corner,
specifically on http://spews.org/html/S359.html, among other places -- I just
happened to have caught it in the act reproducably there.  1.2.1 does not
display the same problem.

Uhm, glad it's not my bug to find. ;)
Dupe.

The latest nightly trunk builds are very good. If you still get this problem
with one of them, please report that to bug 169777 as soon as it is convenient
to do so.

*** This bug has been marked as a duplicate of 169777 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
*** Bug 191686 has been marked as a duplicate of this bug. ***
*** Bug 194375 has been marked as a duplicate of this bug. ***
v
Status: RESOLVED → VERIFIED
(Removing 'Blocks: bug 134576', to clear things up there.)
No longer blocks: FastLoadMeta
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: