Closed Bug 523854 Opened 16 years ago Closed 14 years ago

Firefox fails to unload properly on program exit, requiring system restart to start Firefox again.

Categories

(Firefox :: General, defect)

3.5 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: ringer47787, Unassigned)

Details

(Keywords: hang, Whiteboard: [CLOSEME 2011-2-25])

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Due to some recent change in my system, the firefox.exe process appears not to be unloading when the application is closed (I verified this in Task Manager). The program will not restart when I attempt to do so. The only workaround so far is to restart the system. Also, when starting Firefox, the application sometimes seems to be taking an inordinate amount of time to load. If a tab was open when I closed the previous session, Firefox will often complain of a problem trying to restore the session and prompt me to attempt to recover or start a new session. Reproducible: Didn't try Expected Results: Firefox should exit cleanly and restart properly when opened. I recently installed quite a few Windows patches from a Patch Tuesday release. The problem seems to have begun afterwards, although this is no proof that one has anything to do with the other. However, I am very suspicious, as the patches applied were wide-ranging and attempted to plug a number of security holes.
Keywords: hang
Version: unspecified → 3.5 Branch
So killing firefox.exe does not work?
Have you tried reproducing this in safe mode? http://support.mozilla.com/en-US/kb/Safe+Mode
Do you use Zonealarm on your system ?
(In reply to comment #1) > So killing firefox.exe does not work? This problem has happened on several occasions, and I may have tried to kill the firefox process on one or more of these. If I did, I don't recall the results. But if I do so in future, I will note the results. Generally speaking, it's not a good idea to kill a process because it does not allow the application to close files cleanly and otherwise tidy up behind itself before exiting. So, I'm reluctant to do it, but in this case I will and see what happens.
(In reply to comment #2) > Have you tried reproducing this in safe mode? > http://support.mozilla.com/en-US/kb/Safe+Mode No, I haven't, since I wasn't aware of this capability. I will try this in future and note the results.
(In reply to comment #3) > Do you use Zonealarm on your system ? As a matter of fact, I do. In fact, I recently upgraded from the bare-bones Zonealarm to Zonealarm Pro. This is perhaps unfortunate since it adds to the number of variables and makes it hard to pin down the cause. I did, however, go into Zonealarm's program control and made sure firefox was granted all firewall privileges after this problem began to occur. Does anyone know if Zonealarm may have anything to do with this problem?
There is no difference if you kill the process or shutdown the OS because the OS kills the process during the shutdown if it doesn't respond. As first step we must know if you can kill the process or not. It's very likely that it's caused by ZA of you can't kill it, we have a few known confirmed reports. It's a complete different issue if you can kill Firefox but that it's in most cases caused by installed addon. Running in the Firefox safemode should should be a good test because the safemode disables the addons temporary.
(In reply to comment #7) > There is no difference if you kill the process or shutdown the OS because the > OS kills the process during the shutdown if it doesn't respond. > As first step we must know if you can kill the process or not. It's very likely > that it's caused by ZA of you can't kill it, we have a few known confirmed > reports. > > It's a complete different issue if you can kill Firefox but that it's in most > cases caused by installed addon. Running in the Firefox safemode should should > be a good test because the safemode disables the addons temporary. This problem is very frustrating as it hasn't recurred since I reported it, and I don't know how to reproduce it. What I have discovered is that the version of ZA Pro that I installed sets ZA to operate unnecessarily in debug mode and causes the log file tvDebug.log to grow extremely large as a result. I learned about this problem from an online forum site hosted by ZA and have since turned off debug mode in ZA Pro and deleted the huge archived copies of this log file. I don't know if this has anything to do with the problem I observed with Firefox, but I'm noting it here as a fact. Also, I have tried running Firefox in safe mode but seen no difference in behavior, as the problem has not recurred.
Well, the problem has recurred. I had just closed Firefox and was running CrapCleaner when I noticed the problem. CrapCleaner can clean up cached data from browser sessions, but it first checks to see if the browser is still open, since otherwise it won't be able to clean up the cached data. So, I opened Task Manager and voila, there was the firefox.exe process still active. I successfully killed the process in Task Manager, then proceeded with the cleanup that I had initiated under CrapCleaner. This time, there was no complaint about firefox still being open and the data was purged as expected. I then attempted to restart Firefox to report this incident, and for a moment, I thought Firefox would not restart. I reopened TaskManager and verified that the firefox.exe process had indeed restarted--although Firefox was no longer listed under running applications. Shortly afterward, following a delay of a couple of minutes since I had attempted to restart Firefox, the Firefox GUI was displayed, including the tab that I had closed the browser with previously. The browser continues to behave normally, but I still don't understand why the firefox process in not unloading when I close the browser, forcing me to manually kill the process. Is there normally such a delay between when Firefox is closed and the process is unloaded from memory? Is some signal to the OS to unload the deactivated process not being sent, or is the OS not acknowledging it?
Please ignore Comment #9. I edited it incorrectly. The corrected version follows: Well, the problem has recurred. I had just closed Firefox and was running CrapCleaner when I noticed the problem. CrapCleaner can clean up cached data from browser sessions, but it first checks to see if the browser is still open, since otherwise it won't be able to clean up the cached data. So, I opened Task Manager and voila, there was the firefox.exe process still active--although Firefox was no longer listed under running applications. I successfully killed the process in Task Manager, then proceeded with the cleanup that I had initiated under CrapCleaner. This time, there was no complaint about firefox still being open and the data was purged as expected. I then attempted to restart Firefox to report this incident, and for a moment, I thought Firefox would not restart. I reopened Task Manager and verified that the firefox.exe process had indeed restarted. Shortly afterward, following a delay of a couple of minutes since I had attempted to restart Firefox, the Firefox GUI was displayed, including the tab that I had closed the browser with previously. The browser continues to behave normally, but I still don't understand why the firefox process in not unloading when I close the browser, forcing me to manually kill the process. Is there normally such a delay between when Firefox is closed and the process is unloaded from memory? Is some signal to the OS to unload the deactivated process not being sent, or is the OS not acknowledging it?
I have same problem, but only then Google Gears is installed. Killing firefox.exe helps. But if I open and close FF again, firefox.exe is again in memory. If I open&close FF many times, there will be same amount of firefox.exe processes in memory. Disabling Google gears plug-in resolves the problem. System info: OS - Windows XP SP3 FF - 3.5.5 Google gears - 0.5.33.0 Also, I have posted bug to Google gears team - http://code.google.com/p/gears/issues/detail?id=967
This bug - 523854 is now confirmed by me. Same sitution - I have the latest firefox 3.6. I close all my FF windows, programme closes. When I try to open it again, a dialogue box informs me that FF is already running in the background. When I created this account, and then went to my email to confirm account - it did it again. So I had to use IE. Some additional comments from a noobie; 1. I went around in circles trying to find the correct manner to report this bug. The reporting protocols are confusing. 2. I should be able to email you screenshots - but I cannot find the attachjment button. 3. Everyone I know wants to support FF, but if you make bug reporting complex, then you will get fewer people taking the time to report issues to you. Happy to email them to you if you wish to contact me. Cheers FF friend and user I even went to the effort of getting screenshots for you - but - where do I load them as attachments? I cannot even paste them here for you.
Graham Bates: before you report anything you should run Firefox in the Firefox safemode. (comment #2 ) Do you have the ghostery addon installed, it's known to cause such hangs with FF3.6 >When I created this account, and then went to my email to confirm account - it >did it again. So I had to use IE. And why didn't you close the Firefox process with the windows taskmanager ? >1. I went around in circles trying to find the correct manner to report this >bug. The reporting protocols are confusing. bugzilla is in the developer area of Mozilla.org. Your issue can not be reproduced by us and is usually caused by addons, plugins or broken Firewall software.
Reporter, are you still seeing this issue with Firefox 3.6.13 or later in safe mode or a fresh profile? If not, please close. These links can help you in your testing. http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Managing+profiles
Whiteboard: [CLOSEME 2011-2-25]
This bug has had the CLOSEME tag for several weeks and the date in the tag is far gone. If the reporter can still see this issue, Please retest with Firefox 3.6.x or later and a new profile (http://support.mozilla.com/kb/Managing+profiles). Then please remove the closeme tag in the whiteboard, mark the bug against the proper version and comment on the bug.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.