Closed Bug 186368 Opened 22 years ago Closed 22 years ago

Mozilla 'freezes' for no apparent reason

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 192294

People

(Reporter: tonvannwnhzn, Assigned: asa)

Details

(Keywords: hang, Whiteboard: If 1.3 beta is freezing Windows 9x, read the release notes first)

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021212 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021212 Reproduction of this effect is difficult, but it is appearing repeatedly at usually unexpected times. Sometimes by just calling in the Browser a 'normal' URL. Most pronounced in following situation: - setting of Preferences - trying to set OK - Mozilla freezes Reproducible: Sometimes Steps to Reproduce: 1. See Details 2. 3. Actual Results: Mozilla freezes. Can get out of that by Ctr/Alt/Del and selection of the 'offending' application. No leftover effects to be detected. Need to start-up Mozilla to continue. Expected Results: Freeze should not have happened at all. PC has 800MHz AMD/Duron with 128Mb memory, running Windows98SE, networked [10Mbps]. Software which might have interaction (in my opinion): ZoneAlarm3, McAfee4.5, Trillian0.74
Reporter, please close Mozilla, delete the xul.mfl file in your profile directory, and restart Mozilla. Does that solve the problem?
Keywords: hang
I'm using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210 with hardware and OS similar to the reporter's. I didn't have problems with version 1.3a, but started having unpredictable hangs after installing and using 1.3b. It seems to happen after running the program for a while. Perhaps there's some memory mismanagement and malloc errors? Failure to garbage-collect? The hangs have occurred during both browser and email activity, and there hasn't seemed to be anything predictable about them except that they don't happen right after startup. The operating system isn't tied up. I can start a DOS window, for example. But I tried to start MSIE during a hang and it didn't appear. Using my crash protector that gives a menu on ctl-alt-delete is the only way out those hangs. The crash protector (McAfee Bombshelter) reports that Mozilla isn't responding, and I just end the task. I'm going back to version 1.3a because I don't like to lose new bookmarks, etc due to program hangs.
John, that's bug 192294. If you download and install from scratch a nightly build from Feb 13 or later, that problem is fixed. It will also be fixed in 1.3 final. This bug is different. Reporter, did deleting xul.mfl help?
Have deleted xul.mfl, and saw it reappearing later. Have afterwards not tested enough with Mozilla to give a conclusive statement. Presently using Netscape 7.0 instead of Mozilla which after some use shows the same 'freezing' from time to time. NS Version = Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 Similar to Mozilla for NS7.0 the remedy is Ctrl-Alt-Del followed by Finish: after that, the machine is clean again and Internet-related software can be started . Similar to other reporter I am not able to run software like IE until I have removed Mozilla/Netscape. Have increased the memory to 256Mb, and that seems to give some improvement, but does not completely solve the problem.
Sounds good. Please download and install the nightly trunk build of February 13 or later. Install it into a clean directory. Does that solve the problem?
This is to confirm freezing of 1.3b Build 2003021008 on a PC under Win 982E. It occurs at various times, after a period of use, opening and closing several browser, mail windows. Sometimes freezes other apps as well, but Ctrl-Alt-Del to shutdown Mozilla usually frees them. System resources hit 100%, but no error messages. Suspect a memory leak. Did not have the problem with 1.1 Build 20020826. Deleting xul.mfl does not solve problem. Usually take a couple of hours of use, but on a couple of occasions it happened within a few minutes. If do not shutdown and restart system, problem recurs within half an hour of reopening Mozilla, so resources not completely reclaimed with Mozilla closure.
After further testing it seems that how soon the freeze occurs seems to correlate to how often I mark email as junk and run a filter to move junk to the Junk folder. Since this problem seems to have arrived with the addition of the junk management function, it might be worth while to focus on that function as a possible source of a memory leak. This also suggests another function to be added: an indicator of the impact on system resource consumption of each use of a new feature, showing which operation of which feature had what impact. That would facilitate the tracking down of things like memory leaks and other performance impacts.
This is not bug 192294. This bug was reported before that bug appeared. Please read the release notes for Mozilla 1.3 beta (specifically the first entry in the second paragraph).
Whiteboard: If 1.3 beta is freezing Windows 9x, read the release notes first
--> Browser-general. Reassign.
Assignee: sspitzer → asa
Component: Mail Window Front End → Browser-General
Product: MailNews → Browser
QA Contact: olgam → asa
Reporter, can you reproduce this in the latest nightly trunk build?
Found the problem was getting much worse, so that I couldn't run Mozilla for more than a couple of minutes, but after I renamed the xul.mfl file in the oc6aroad.slt directory and restarted Mozilla the problem is greatly alleviated. Not completely eliminated, but at least alleviated to the point where I can work for a few hours at a time. At the point I renamed it, the xul.mfl file was 3312 KB. Initially, the new xul.mfl file was about 1500 KB, but after a day of use, is now up to 2285 KB. I will track its growth, and rename it again during periods when Mozilla is not launched, as a way to manage the problem. Is it worth saving those old xul.mfl files for analysis?
For some reason the problem is getting worse. Can't go more than a few minutes without freezing. What is the latest release that I can drop back to to avoid the problem? I will have to abandon 1.3b 2003021000 unless the problem is fixed soon.
In response to a direct email from Andrew Hagen <xah@myrealbox.com> (which address is rejecting email from me): I read the release notes before posting the first message. I previously downloaded and installed the latest build of 1.3b this morning (2003021008, which is the same I was running when I first encountered the problem) and the problem did not get fixed, although it seems to be worse when viewing some sites than others, such as www.dell.com and the .asp pages that allow one to configure a system prior to purchase. Am running Win 98se. Just trying to offer observations that might help someone find and fix the problem.
Did you install the latest build into an empty subdirectory?
I uninstalled Mozilla first, but reinstalled into the same directory. Didn't check whether it was empty, but why should that make a difference? Are you saying the problem is a residual file that uninstall doesn't remove? If so, which one?
Okay, have reinstalled into newly created directory. No freeze yet, but I will continue to test and report back. Had to reinstall the spellchecker and copy over the plugins.
Tested newly installed 1.3b into empty directory on www.dell.com, and proceeded to try to configure a Dell Inspiron notebook with various options. Got as far as http://configure.us.dell.com/dellstore/config.aspx?cs=04&oc=i8200sbe&m_11=WPXP&m_1=CM24BHM&m_22=ICOREL&c=us&l=en&keycode=6W300 and browser froze. So ctrl-alt-del to close, deleted xul.mfl file, rebooted. Browser proceeded to open same page above, since it is set to open last file, and browser immediately froze. Have not yet encountered problem with other sites, but will continue to test and report.
1.3b build 2003021008 froze again on Win 98se on my own website, after having retrieved a few messages, apparently not after user input, but while just idling. I had previously deleted the xul.mfl file, which I now do before every bootup. Problem is definitely not fixed, although it possibly takes somewhat longer to appear than was the case yesterday. Does anyone have a theory as to what is causing this?
I've noticed this too. It occurs randomly so, you can't specify where the problem consistently occurs. The first couple of times this happened, I couldn't get out of the program by using "Ctrl-Alt-Del" so, I ended up having to push the "reset" button on the computer. When the computer booted up, I got the typical message "Because Windows was not shut down properly ... etc." and the "exercise" found lost clusters". When I saved these files as "file000x" and viewed them, they looked like html pages and usually had some reference to Mozilla on them. Since this happened the first couple of times that Mozilla froze after installing 1.3b, and it hadn't ever happened in 1.3a, I thought that maybe I had lost a file that Mozilla needed and so, I reinstalled it. However, after reinstallation, Mozilla is still randomly freezing.
Colleen, did you check the status whiteboard? Have you read the release notes? The hang you are experiencing is a known problem. It is fixed in the nightly builds. You should either install the latest nightly build into an empty directory, or wait for 1.3 final. Jon, that is not the latest nightly build. Get this file: ftp://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk/mozilla-win32-installer-sea.exe Then uninstall Mozilla. Then decide where to install the nightly build. The subdirectory should be empty. Then run the file, above, that you just downloaded.
Okay. Can't presume us newbies know where the nightly builds are. :) We'll see if this fixes the problem. So far so good. Unfortunately, many of us user-testers don't have the time to thoroughly explore the mozilla.org and mozdev.org sites to find where everything is. If time were not so short I'd love to get in and code some of the enhancements I want. They'd probably get done faster if I did. :) Alas, remaining life is short and I have about 26,000 years' worth of tasks to be done before I'm gone. Need to delegate.
If you disagree, please reopen *** This bug has been marked as a duplicate of 192294 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
I request this be re-opened, or, if appropriate, given a new number. The problem has continued through every version up to and including 1.6, and I question whether it really is a dupe of #192294 or #195456. The symptom remains: after a period of use, the connection to the network is lost, despite connection being available to other apps. Can use all functions of Mozilla that do not involve access to the network. Have to close Mozilla completely and reopen to get connectivity to the network.
This bug involved a Mozilla freeze, or hang. The problem as stated in the previous comment does not involve a Mozilla freeze or hang. Rather it involves Mozilla's networking component ceasing to work. That is a different bug. If you are having a problem in current Mozilla builds, file a new bug. Feel free to CC me to it.
I have added Bug #233563 after deciding that Bug #206107 doesn't seem to fit.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.