Closed Bug 333951 Opened 18 years ago Closed 18 years ago

Update to 1.5.0.2 fails (FF endlessly tried to install update / launch)

Categories

(Toolkit :: Application Update, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED DUPLICATE of bug 340535

People

(Reporter: the-pooh, Unassigned)

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Firefox/1.5.0.1


(1) FF (version 1.5.0.1, the official release) automatically updated to 1.5.0.2, downloaded the file and asked me if I'd like to install now or later (on the next startup). 

(2) I clicked later. 

(3) When trying to restart FF, I saw a progress bar (the installation progress?) 

(4) It stopped after about 33% and the window closed

(5) MessageBox appeared that told me that I should check if I have permission to modify files (which, of course, I have!). The box only had an 'OK'-Button.

Steps (4) and (5) repeated infinitely (I had to kill the process in the task manager)

Since I could start FF anymore (even after rebooting Windows) I had to uninstall the 1.5.0.1, download the full 1.5.0.2 installer and install it manually.

Reproducible: Didn't try

Steps to Reproduce:
Cannot try to reproduce, because 1.5.0.2 is installed now (and I won't risk the described procedure again).
Actual Results:  
As already mentioned, I couldn't start FF anymore and had to re-install the full software.

Expected Results:  
I'd apprechiate that the update system works without that critical bugs :-)
Is your Windows user account of Administrator level privileges ? Or something which has "Full Control" of C:\Program Files\Mozilla Firefox ? If not, the updater could not access some of the files.

Or, have you ever restored C:\Program Files\Mozilla Firefox from backup ? That might lead to files being read only (in the old style FAT attributes).

Also, is there a file C:\Program Files\Mozilla Firefox\updates\last-update.log ? Please attach it to this bug if you find it.
Attached file The update log file.
> Also, is there a file C:\Program Files\Mozilla Firefox\updates\last-update.log
> ? Please attach it to this bug if you find it.

Here it is. I can also serve with an install_status.log and an install_wizard.log. They are both laying in the root folder and were both modified today. There is also an install.log, but this is much older. Do you like me to also attach these files?
(In reply to comment #1)
> Is your Windows user account of Administrator level privileges ? Or something
> which has "Full Control" of C:\Program Files\Mozilla Firefox ? If not, the
> updater could not access some of the files.

My user has full administrator rights. 


> Or, have you ever restored C:\Program Files\Mozilla Firefox from backup ? That
> might lead to files being read only (in the old style FAT attributes).

Actually, I might have installed/reinstalled FF with the installer. But as far as I remember, I never copied FF from a backup folder by myself -- if that was the question.

On another computer I still have FF 1.5.0.1 installed. Should I try to reproduce the hanging? Which files are of particular interest? At which steps in the update procedure should I look at them (copy them)? Need screenshots? 
From your update log, it seems AccessibleMarshal.dll did not match what Firefox expected to find. You could try to reproduce the bug with this second machine, but I suspect that the first bug was something to do with the history of your Firefox install and not readily recreated.
Just wanted to mention that I encountered the same behaviour with the 1.5.0.3 update. The log was the same and I had to uninstall FF again, deleted the installation (just to be sure) and installed the 1.5.0.3 with the full installer. 

Why do I get the same error after I completely deleted 1.5.0.1 and installed 1.5.0.2 from scratch? Is it my profile (which is of course the same as in the past)? Or my extensions?
I don't think your profile or extensions have any affect on the update process, but given that completely removing the application install doesn't help perhaps it is worth testing. Just a check though, when you say things like "completely deleted 1.5.0.1", do you mean that C:\Program Files\Mozilla Firefox\ was either empty or no longer existed ?

Safe mode testing steps:
1, uninstall 1.5.0.3 and make sure everything is deleted from C:\Program Files\Mozilla Firefox (assuming you installed it there). You can leave the plugins directory if you like.
2, install 1.5.0.2, check that it can connect to the network ok, and close it. 
3, use the "Mozilla Firefox (Safe Mode)" shortcut in the start menu to load Firefox with extensions disabled. Don't reset any settings, just use the "Continue to safe mode" button.
4, Help > Check for updates, d/l and install the update
5, see if the update applies successfully and report back.
> Just a check though, when you say things like "completely
> deleted 1.5.0.1", do you mean that C:\Program Files\Mozilla Firefox\ was either
> empty or no longer existed ?

Before testing: Yes. I uninstalled FF via Control Panel -> Software and then deleted the folder where I installed it (not "C:\Program Files\Mozilla Firefox" but a custom folder...).
Well, I followed the steps you told me and everything went without problems. It updated to 1.5.0.3 and restarted.

But actually I thought about it and must revise my previous comment. It doesn't make sense that I deleted the folder when the 1.5.0.1 was installed and the problem occured in the first time. How should I've been able to give you the OLD log file? If I'd deleted the folder, the log wouldn't be there after installing 1.5.0.2, would it? Thus, one must conclude that I didn't deleted the folder at all. I obviously only uninstalled the 1.5.0.1 via Control Panel and installed 1.5.0.2 in the same (still existing) folder. So when the 1.5.0.3 update came, the dll was most likely the old one... (Btw., its quite confusing with all that version numbers and installs and folders and deletions, isn't it?)

When looking at my bug report, I get confirmed:

> Since I couldn't start FF anymore (even after rebooting Windows) I had to 
> uninstall the 1.5.0.1, download the full 1.5.0.2 installer and install it 
> manually.

Nothing said about deleting a folder....


Do you agree with my reconstruction of what happend?
Yes, it sounds like the initial uninstall of 1.5.0.1 wasn't a complete one - in general that's quite normal, new files aren't supposed to be removed but AccessibleMarshal.dll should have been. 

I guess we have to go back to the idea that AccessibleMarshal.dll had broken permissions, or perhaps it was in use when uninstalling. That could also have prevented the manual install of 1.5.0.2 from replacing that file, which would break the update to 1.5.0.3. I'm surprised the installer didn't fail at that point.
Hi, I'm back again, this time with the update to 1.5.0.5 which failed again. When updating from 1.5.0.3 to 1.5.0.4 I removed the whole FF folder before installing 1.5.0.4. The new update showed the same behaviour. I saved the update.log after the automatic update to 1.5.0.5 before I removed the folder where the 1.5.0.4 was installed. At the very end there is a "failed: 7; calling QuitProgressUI" reported, but have a look for yourself, I attachted the file...
This time firefox could not be patched:
  EXECUTE PATCH firefox.exe
  ### execution failed

That can be because Firefox doesn't exit properly and the file is still in use. If you quit Firefox by closing the last window, is firefox.exe silll in the Process List of the Task Manager ? How about if you go File > Exit instead ?
(In reply to comment #13)
> This time firefox could not be patched:
>   EXECUTE PATCH firefox.exe
>   ### execution failed
> 
> That can be because Firefox doesn't exit properly and the file is still in use.
> If you quit Firefox by closing the last window, is firefox.exe silll in the
> Process List of the Task Manager ? How about if you go File > Exit instead ?
> 

Well, I can't tell you, because now I manually installed 1.5.0.5. But what about other processes that have a handle to firefox.exe? I've YzDock installed, a rebuild of the MAC OSX dock bar. I think that it opens a handle to the exe. When I wanted to remove the FF folder after the installation failed, the explorer got panicked because firefox.exe was in use by another application (YzDock). Would this be an explanation for everything? If so, can't the update routine close the handle?
That sounds pretty likely to me. Why does YzDock need to grab firefox.exe like that ? Bad design ?
(In reply to comment #15)
> That sounds pretty likely to me. Why does YzDock need to grab firefox.exe like
> that ? Bad design ?
> 

Don't ask me. I only downloaded it and fortunately can't be blamed for it :-). But one might could test on another machine if this really is the cause of the problem. Simply open a handle to firefox.exe and see what happens when the updater works...
With update 1.5.0.6 I found out that it is indeed this Mac like dock bar that causes the failure. FF automatically installed the update and with the next restart it was all the same as with every other update and the installation failed in the first time. But (and that's new): After the first attempt I killed the dock bar process and - you won't believe it - the update finished as if there have never been a problem. So from now on I'm eagerly awaiting the future updates :-).

But one question arises still: Can't the updater figure out if another process grabbed a file that is to be updated/replaced? Tools like the Process Explorer are also able to display information about open handles. Or, if that's impossible, one could maybe give a hint in the error message (in the moment only the user's privileges and possible write protection is mentioned).
Duplicate of bug 340535?
I think so...
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: