522190 - App update failed, left a 0-byte firefox.exe.

Status: RESOLVED WORKSFORME

(Toolkit :: Application Update, defect)

Description

[Justin Dolske [:Dolske]]

Attachment: updates/0/update.log

Shaver experienced epic updater fail a couple weeks ago [and, ahem, I an just now getting around to filing it. :(].

As I recall, the basic steps to having caused this were:

1) Firefox running with existing session
2) Launch Firefox again
3) Updater started, displayed UAC prompt
4) Clicked cancel at prompt
5) Updater ran anyway (?), and screwed up appdir.

I've got a copy of the updates dir and appdir; too big to attach everything here. But I'll attach the last 2 update logs.

Comment 1

[Justin Dolske [:Dolske]]

Attachment: updates/last-update.log

update.log was from Sep 21st, last-update.log is from Sep 17th.

The 21st update failed, but so did the one from the 17th.

[shaver's appdir] $ ls -l crashreporter* firefox.exe* freebl*
      0 Sep 21 16:39 crashreporter-override.ini
      0 Sep 21 16:39 crashreporter.exe
  95232 Sep 21 16:39 crashreporter.exe.moz-backup
      0 Sep 21 16:39 crashreporter.ini
      0 Sep 21 16:39 firefox.exe
      0 Sep 21 16:39 firefox.exe.moz-backup
      0 Sep 21 16:39 freebl3.chk

Interesting that even the firefox.exe backup file is 0-byte.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Can you reproduce this? I suspect that it has a lot to do with someone launching Firefox with no-remote as an option, at which point I don't think it would block, though it would be massively inconvenient.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Not blocking until we get confirmed STR; Juan, can we get someone poking at this a little?

Comment 4

[Robert Strong (they/them - no direct email)]

So, if we get the UAC prompt the installation is under Program Files which we don't have permissions for by default. If the UAC prompt is canceled then we don't have write access to the installation directory AND we exit well before the code to attempt to update. For these reasons I highly doubt that these are the steps to reproduce.

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/updater/updater.cpp#1506

Comment 5

[Andreas Jung]

The same (or at least a very similar) bug occurred to me today.
The trunk nightly had downloaded an update and prompted me to install it.
Therefore I quit Minefield and opened it again.
It showed the update progress window and then a message that the update failed.
Afterwards Minefield started but hang after a few seconds. (*)
I checked the program folder to see if I can spot the error and the program folder contents seemed fine except for mozilla-runtime.exe and crashreporter.exe which had been replaced with 0-byte files.
I'm on Windows XP SP3, so if it is the same bug it means that the bug isn't specific to Vista or UAC, because on Windows XP there exists no UAC.

No other instance of firefox/minefield was running at the time the update was started. I don't have an idea why the update failed and no steps to reproduce :(

(*) I will file a bug for this, Minefield should really handle a not existing/damaged mozilla-runtime.exe better than hanging...

Comment 6

[Andreas Jung]

> (*) I will file a bug for this, Minefield should really handle a not
> existing/damaged mozilla-runtime.exe better than hanging...

see bug 535077

Comment 7

[Robert Strong (they/them - no direct email)]

Please attach (using the 'Add an attachment' link above) the last-update.log which can be located with a default install as follows:

for Windows Vista and above type the following in the Start Menu search box and press return.
%LOCALAPPDATA%
Then navigate to \Mozilla\Firefox\Mozilla Firefox\updates\

for Windows prior to Windows Vista type the following in the Start Menu -> run box and press return.
%USERPROFILE%
Then navigate to \Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\updates\

If there is a backup-update.log file in this directory please attach it as well.

Comment 8

[Andreas Jung]

In \Lokale Einstellungen\Anwendungsdaten\Mozilla\Firefox\Mozilla Firefox\updates\ there is neither a last-update.log nor a backup-update.log (I use a German Windows XP so the path is localized).

Note: Since Minefield always hung after a few seconds (because of the invalid mozilla-runtime.exe), I used (the also installed) Firefox 3.6 (with a separate user profile) to download the full installer for the trunk nightly to reinstall Minefield. Could this have deleted the log files?

Comment 9

[Robert Strong (they/them - no direct email)]

The installer will delete the log files on install which will be changed sometime in the future. If this happens again please get a copy of the log files before running the installer. Thanks

Comment 10

[Andreas Jung]

I checked with data recovery software if the files still exist on the hard disk, but it seems they were already overwritten. Only update.status could be restored, which contained:
failed: 7

> If this happens again please get a copy of the log
> files before running the installer. Thanks

I hope it doesn't happen again, but if it does I will copy the files before running the installer.

> The installer will delete the log files on install which will be changed
> sometime in the future.

Is there a bug I can watch?

Comment 11

[Robert Strong (they/them - no direct email)]

failed: 7 is a write error but the main diagnostic info is in the update.log and last-update.log

Bug 552039 is to stop deleting the update log files on install

Comment 12

[Andreas Jung]

Attachment: zip file including update.log and last-update.log

The problem appeared again. This time crashreporter.exe was replaced with a 0-byte file and some other files might have been damaged, because it was impossible to start Minefield after the failed update.

I also have the messed up program folder in a zip file. If you need it, I can upload it as well...

Comment 13

[Robert Strong (they/them - no direct email)]

If you can upload the messed up program folder somewhere it might shed some light. If not, we can work out another way to get it to me. Also, is the system low on disk space?

Comment 14

[Robert Strong (they/them - no direct email)]

The update.log was for a full update and failed on toolkit.jar. Are there any reasons you can think of why it would fail on it? Has it been modified for example?

The last-update.log failed on crashreporter.exe which was likely due to it being open. I might one off crashreporter.exe in the updater to first verify that it isn't open before trying to apply an update or figure out a way to copy it before launching it so it isn't in the way.

Comment 15

[Andreas Jung]

System Info:
(German) Windows XP Service Pack 3
Intel Pentium D 3.40 GHz
1.50GB RAM (about 700MB free)
E:\ 13.5GB (about 400MB free)
(^Windows Partition; Minefield is installed in E:\Programme\Minefield)

the messed up program folder: http://www.mediafire.com/?25mrgmnwhkw

the updates folder: http://www.mediafire.com/?mndzizqmwdt

(In reply to comment #14)
> The update.log was for a full update and failed on toolkit.jar. Are there any
> reasons you can think of why it would fail on it? Has it been modified for
> example?

No, I did not modify it. I have no clue why it failed on it.

Comment 16

[Robert Strong (they/them - no direct email)]

There have been several changes to the way the primary executable is updated in the last year and since there have been no more reports of this happening I am resolving it as wfm. If this happens to shaver again, please reopen. If you are not shaver and this happens again, please file a new bug so I can keep the details from each reporter separate for my sanity.