Closed Bug 515415 Opened 10 years ago Closed 10 years ago

[WinCE] Software Update not being applied

Categories

(Toolkit :: Application Update, defect, critical)

1.9.2 Branch
ARM
Windows CE
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: marcia, Assigned: blassey)

References

Details

(Keywords: verified1.9.2, Whiteboard: [nv])

Attachments

(2 files, 4 obsolete files)

Attached file 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.
I wonder if the fastload work is interfering. Does it apply after restarting the OS?
Severity: normal → critical
I restarted the OS yesterday and it did not have any effect.
Whiteboard: [nv]
Marcia, could you hunt down the regression range?
Attached patch patch rev1 (obsolete) — Splinter Review
It appears that on Marcia's system the working directory doesn't end with a slash.
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #399557 - Flags: review?(vladimir)
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 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.
Attachment #399557 - Attachment is obsolete: true
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?
(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.
Flags: blocking1.9.2? → blocking1.9.2+
Attached patch patch (obsolete) — Splinter Review
Attachment #399597 - Flags: review?(doug.turner)
Comment on attachment 399597 [details] [diff] [review]
patch

no content; no review.
Attachment #399597 - Flags: review?(doug.turner) → review-
Attached patch patch (for real) (obsolete) — Splinter Review
err...still getting used to this whole hg thing I guess
Assignee: nobody → bugmail
Attachment #399597 - Attachment is obsolete: true
Attachment #399602 - Flags: review?(doug.turner)
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.
Attachment #399602 - Flags: review?(doug.turner) → review-
Brad, any update? I'd like to get this fixed on 1.9.2 ASAP for bug 514307.
Attached patch patch v.2 (obsolete) — Splinter Review
Attachment #399602 - Attachment is obsolete: true
Attachment #399753 - Flags: review?(doug.turner)
Attachment #399753 - Flags: review?(doug.turner) → review+
Attached patch patch v.3Splinter Review
GetModuleFileName => GetModuleFileNameW

minor change, carrying the review
Attachment #399753 - Attachment is obsolete: true
Attachment #399758 - Flags: review+
Attachment #399758 - Flags: approval1.9.2?
pushed http://hg.mozilla.org/mozilla-central/rev/2246abd2c17e
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Would you like some extra "nightly" builds in the update system to verify this fix "in the wild" ?
Comment on attachment 399758 [details] [diff] [review]
patch v.3

No approval needed, bug is blocking
Attachment #399758 - Flags: approval1.9.2?
(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.
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.
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.
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.
Keywords: verified1.9.2
You need to log in before you can comment on or make changes to this bug.