Closed Bug 410485 Opened 12 years ago Closed 12 years ago

Updates from 20080101 Win32 nightly fail with READ_ERROR

Categories

(Toolkit :: Application Update, defect, blocker)

x86
Windows XP
defect
Not set
blocker

Tracking

()

RESOLVED FIXED

People

(Reporter: nthomas, Assigned: benjamin)

References

Details

(Keywords: regression)

Attachments

(1 file)

A bunch of nightly testers noticed this, and Jim Jeffrey mentioned it on IRC - if you try to update the 20080101 Win32 nightly then it fails with these lines in the last-update.log:

  failed: 6
  calling QuitProgressUI

That's READ_ERROR according to http://mxr.mozilla.org/mozilla/source/toolkit/mozapps/update/src/updater/errors.h. Same result for both the partial and the complete update. You end up in an update loop - partial d/l, fails, complete d/l, fails, offered update again. I've tested Mac partial/complete and it is not affected.

Updating earlier win32 builds with the complete works fine, as does forcing a complete with the 20080101 nightly and the 20071231 updater.exe copied in. So I believe this is an issue with updater.exe. In particular bug 396052, which landed at 2007-12-31 07:15 PST and would affect updates from 20080101 nightlies.
Flags: blocking-firefox3?
Keywords: regression
Summary: Updates from 20080101 nightly fail with READ_ERROR → Updates from 20080101 Win32 nightly fail with READ_ERROR
All mine... I'm going to take a while to debug this before thinking about a backout, but I've asked cf to pull the nightly update so that more users don't end up in a horked state.
Assignee: nobody → benjamin
Severity: critical → blocker
Flags: blocking-firefox3? → blocking-firefox3+
(In reply to comment #1)
> All mine... I'm going to take a while to debug this before thinking about a
> backout, but I've asked cf to pull the nightly update so that more users don't
> end up in a horked state.

This is done, for both updating _from_ 20080101, and updating _to_ that build (so that people with 20080101 don't up in a loop, and anyone not already with the duff updater won't get it). Of course, this only sticks until the next clobber/nightly build comes along. No pressure :-)
Severity: blocker → critical
Flags: blocking-firefox3+ → blocking-firefox3?
Ugh, I hate it that MSVC doesn't issue good warnings for this: in any case, you can't sprintf "%s" a wide-character string, and fixing that involves adding some wide-character equivalents up the API chain.

I didn't catch this before because I was using a single-character directory name to test the updater... "a" instead of "updates", which happened to be the same in UCS2 and ASCII.

We need unit-tests for the updater :-(
Attachment #295107 - Flags: review?(ted.mielczarek)
Severity: critical → blocker
Flags: blocking-firefox3? → blocking-firefox3+
Attachment #295107 - Flags: review?(ted.mielczarek) → review+
Fixed on trunk. I triggered a clobber to get new win32 nightlies.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Confirmed with 
  20080101 nightly + updater.exe from the 10:16 hourly 
    + 20080102 complete mar + custom update.xml

People with the 2008010104 & 2008010205 nightly builds (or equivalent hourlies) will need to download the installer to get back on track.
Just to point on the may be obvious but today's Thunderbird trunk build
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010103 Thunderbird/3.0a1pre ID:2008010103
is suffering from the same bug. Will the patch be applied there as well?
(In reply to comment #6)

Yes, it's shared code for all Toolkit applications (eg Firefox, Thunderbird, Sunbird).
(In reply to comment #5)
> Confirmed with 
>   20080101 nightly + updater.exe from the 10:16 hourly 
>     + 20080102 complete mar + custom update.xml
> 
> People with the 2008010104 & 2008010205 nightly builds (or equivalent hourlies)
> will need to download the installer to get back on track.
> 
Just to be sure, don't you mean 2008010104 & 2008010105 builds.
And the fix would be to download a full zip or installer build. Correct.
Which means I got lucky in skipping the 200801 update, and getting a full
for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010204 Thunderbird/3.0a1pre ID:2008010204

No, he meant the 2008010104 & 2008010205 builds (of Firefox). The 2008010211 build is the one that has the fixed updater.exe.

Since I did not force a new Thunderbird nightly, there won't be a fixed tbird build until tomorrow morning's nightly.
Duplicate of this bug: 411000
Duplicate of this bug: 411056
The software update bug in Minefield and Thunderbird still shows up. The short update download does not get installed neither the long update download.  This happens just now using update 20080106 for both products and trying to update to 20080107
(In reply to comment #12)
> The software update bug in Minefield and Thunderbird still shows up. The short
> update download does not get installed neither the long update download.  This
> happens just now using update 20080106 for both products and trying to update
> to 20080107

WFM with the Firefox Win32 2008010605 zip. Please file a separate bug with more details.

Duplicate of this bug: 411465
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.