326917 - Every few minutes an Auto-Update exception appears on Console

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Rod Taylor]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.0.1) Gecko/20060204 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.0.1) Gecko/20060204 Firefox/1.5.0.1

Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXULRuntime.XPCOMABI]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: file:///usr/X11R6/lib/firefox/components/nsUpdateService.js :: anonymous :: line 1689"  data: no]
Source File: file:///usr/X11R6/lib/firefox/components/nsUpdateService.js
Line: 1689


Line 1689 is this:
     url = url.replace(/%BUILD_TARGET%/g, gApp.OS + "_" + gApp.XPCOMABI);


Reproducible: Always

Comment 1

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

Reversing incorrect component change, sorry for bugspam.

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I ran into this a few days ago with a XULRunner binary built on an AMD64x2 machine. The basic problem is that gApp.XPCOMABI throws an exception if it isn't available rather than simply returning an empty string (why?). A simple try/catch fixes this on the client side, but then you'll run into further problems when the update url is sent to AUS.

I guess the real question is why your TARGET_XPCOM_ABI var isn't being set in configure. CC'ing bsmedberg.

FWIW I think we should fix the update service to either fail gracefully or append an empty string to the update url if gApp.XPCOMABI throws this exception.

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch v1.0 that strips the ABI string from the update url if TARGET_XPCOM_ABI is not available

This patch simply pulls the ABI string from the update url. I don't know if this will work with AUS, though.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #3)
> Created an attachment (id=211608) [edit]
> patch v1.0 that strips the ABI string from the update url if TARGET_XPCOM_ABI
> is not available

See also bug 323330. That case falls back to "unknownABI", might want to do the same here (though I'm not sure whether the server side handles these cases differently).

Comment 5

[Benjamin Smedberg]

Comment on attachment 211608 [details] [diff] [review]
patch v1.0 that strips the ABI string from the update url if TARGET_XPCOM_ABI is not available

Having .xpcomABI throw is by design, because configure doesn't have enough information to know what the ABI is.

In this case software update should fail completely (it should not even try to update the app, because it does not have enough information to do so).

Comment 6

[Ben Turner (not reading bugmail, use the needinfo flag!)]

So then the question is how will this become known to the user. We can add a check to the canUpdate function that will return false if the ABI is unknown, but that will just disable the service without notifying the user. We could also pop up a dialog of some sort, perhaps even using the download-failed poage from updates.xul. Thoughts?

I'm certainly curious to know which configurations cause the ABI to remain unresolved.

Comment 7

[Benjamin Smedberg]

I think that we should silently disable all auto-update mechanisms if we don't know what the XPCOM ABI is.

configure.in has various tests to determine what the XPCOM ABI is... if either of the compiler ABI or processor architecture is uncertain the value is not set: see http://lxr.mozilla.org/mozilla/source/configure.in#1053

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Attachment: patch to disable the update service

This patch will disable the update service in the event that TARGET_XPCOM_ABI is not set.

Comment 9

[Benjamin Smedberg]

Please don't land this patch, I'm going to incorporate it into bug 323328

Comment 10

[Benjamin Smedberg]

Fixed by bug 323328 on trunk, 1.8, 1.8.0