515415 - [WinCE] Software Update not being applied

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Marcia Knous [:marcia]]

Attachment: Updates file

Seen while running the 20090908 nightly, although I think I first noticed this on Monday when I tried to update my build.

STR:
1. With a nightly build running, try to perform a software update.
2. The update downloads but never applies.

I have attached the updates file. I have also reset the OS and started from scratch trying to update from a 20090831 build and the same thing happens.

Comment 1

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

I wonder if the fastload work is interfering. Does it apply after restarting the OS?

Comment 2

[Marcia Knous [:marcia]]

I restarted the OS yesterday and it did not have any effect.

Comment 3

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

Marcia, could you hunt down the regression range?

Comment 4

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

Attachment: patch rev1

It appears that on Marcia's system the working directory doesn't end with a slash.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hm, though after having just r+'d that, won't that cause problems if for whatever reason we happen to be in the root dir?  In that case, "\\" will be the start of a network path, no?

Comment 6

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

Comment on attachment 399557 [details] [diff] [review]
patch rev1

true :(

The cwd is returned from the WinCE environment implementation. Perhaps that could be fixed so what it returns is consistent?

I'm going to take a look at this a little later after I finish up bug 471219.

Comment 7

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

Brad, it appears that _wgetcwd sometimes returns the path without the trailing \ on WinCE. Could you take a look at what might be causing this?

Comment 8

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #7)
> Brad, it appears that _wgetcwd sometimes returns the path without the trailing
> \ on WinCE. Could you take a look at what might be causing this?

we have no checks to ensure that.  I'll get a patch together.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch

Comment 10

[Doug Turner (:dougt)]

Comment on attachment 399597 [details] [diff] [review]
patch

no content; no review.

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch (for real)

err...still getting used to this whole hg thing I guess

Comment 12

[Doug Turner (:dougt)]

Comment on attachment 399602 [details] [diff] [review]
patch (for real)

>-      dir = (unsigned short*)malloc(sizeof(unsigned short) * (wcslen(tmp) + 1));
>+      dir = (unsigned short*)malloc(sizeof(unsigned short) * (wcslen(tmp) + 2));
>     wcscpy(dir, tmp);

Test for failure.  not yours, but it is now. ;-)


>-    return dir;
>+  } else {
>+    unsigned long i;
>+    if (!dir)
>+      dir = (unsigned short*)malloc(sizeof(unsigned short) * (MAX_PATH + 1));

Test for failure.

>+    for (i = _tcslen(dir); i && dir[i] != TEXT('\\'); i--) {}

_tcslen or wcslen?  Which one is the right one to use?


also we should test for failure on GetModuleFileName.

Comment 13

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

Brad, any update? I'd like to get this fixed on 1.9.2 ASAP for bug 514307.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch v.2

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

Attachment: patch v.3

GetModuleFileName => GetModuleFileNameW

minor change, carrying the review

Comment 16

[Brad Lassey [:blassey] (use needinfo?)]

pushed http://hg.mozilla.org/mozilla-central/rev/2246abd2c17e

Comment 17

[Nick Thomas [:nthomas] (UTC+12)]

Would you like some extra "nightly" builds in the update system to verify this fix "in the wild" ?

Comment 18

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 399758 [details] [diff] [review]
patch v.3

No approval needed, bug is blocking

Comment 19

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

Pushed to mozilla-1.9.2
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/b57dd5f63c62

Comment 20

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

(In reply to comment #17)
> Would you like some extra "nightly" builds in the update system to verify this
> fix "in the wild" ?
I haven't personally been able to reproduce though Marcia's update log made it pretty clear what the problem was so I don't think extra nightly updates would provide much but if it isn't too much trouble it wouldn't hurt.

Comment 21

[Nick Thomas [:nthomas] (UTC+12)]

I triggered another nightly, so that Marcia can take the hourly with the fix and update to that.

I'll let you know the d/l link to the hourly when it and the nightly are done.

Comment 22

[Nick Thomas [:nthomas] (UTC+12)]

Marcia, hourly build is at
  http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.2-wince/1252633301/firefox-3.6a2pre.en-US.wince-arm.zip
and should update to the 20090910184711 nightly, or the 20090911 one if that comes out in the meantime.

Comment 23

[Marcia Knous [:marcia]]

I was able to perform a successful update from the build referenced in Comment 22 to the latest 20090911 nightly. I mentioned to rstrong that I did crash the first time I checked for updates, but that could be unrelated. Adding verified keyword.

(In reply to comment #22)
> Marcia, hourly build is at
>  
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-1.9.2-wince/1252633301/firefox-3.6a2pre.en-US.wince-arm.zip
> and should update to the 20090910184711 nightly, or the 20090911 one if that
> comes out in the meantime.