1900991 - Startup errors on artifact nightly builds - NS_ERROR_XPC_GS_RETURNED_FAILURE

Status: RESOLVED INCOMPLETE

(Toolkit :: Application Update, defect)

Description

[:Gijs (he/him)]

NS_ERROR_XPC_GS_RETURNED_FAILURE: ServiceManager::GetService returned failure code:
    defineLazyServiceGetter resource://gre/modules/XPCOMUtils.sys.mjs:141
    task resource:///modules/BrowserGlue.sys.mjs:3064
    _scheduleStartupIdleTasks resource:///modules/BrowserGlue.sys.mjs:3205
XPCOMUtils.sys.mjs:145:17
UpdateServiceStub @mozilla.org/updates/update-service-stub;1 XPCOMUtils.sys.mjs:146:17
TypeError: can't access property "updateDisabledForTesting", lazy.UpdateServiceStub is undefined
BrowserGlue.sys.mjs:3064:13

stack:

defineLazyServiceGetter resource://gre/modules/XPCOMUtils.sys.mjs:141
    task resource:///modules/BrowserGlue.sys.mjs:3064
    _scheduleStartupIdleTasks resource:///modules/BrowserGlue.sys.mjs:3205
XPCOMUtils.sys.mjs:145:17
    defineLazyServiceGetter resource://gre/modules/XPCOMUtils.sys.mjs:145
    task resource:///modules/BrowserGlue.sys.mjs:3064
    _scheduleStartupIdleTasks resource:///modules/BrowserGlue.sys.mjs:3205

This appears to be from:

      {
        name: "BackgroundUpdate",
        condition: AppConstants.MOZ_UPDATE_AGENT,
        task: async () => {
          // Never in automation!
          if (
            AppConstants.MOZ_UPDATER &&
            !lazy.UpdateServiceStub.updateDisabledForTesting
          ) {
            try {
              await lazy.BackgroundUpdate.scheduleFirefoxMessagingSystemTargetingSnapshotting();
            } catch (e) {
              console.error(
                "There was an error scheduling Firefox Messaging System targeting snapshotting: ",
                e
              );
            }
            await lazy.BackgroundUpdate.maybeScheduleBackgroundUpdateTask();
          }
        },
      },

where the condition is presumably not right?

Comment 1

[:Gijs (he/him)]

(the service UpdateServiceStub @mozilla.org/updates/update-service-stub;1 does not appear to exist on my Windows artifact build from central this morning; it's not clear to me if that's a new development or has just been broken for longer or what.)

Comment 2

[:Gijs (he/him)]

I guess bug 1875502 introduced the update service stub reference so 127 should be fine.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1875502

:bytesized, since you are the author of the regressor, bug 1875502, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Robin Steuber (she/her) [:bytesized]]

I'll try to investigate this further as soon as I have the capacity. In the meantime though,

(In reply to :Gijs (he/him) from comment #0)

where the condition is presumably not right?

Not sure what this means?

(In reply to :Gijs (he/him) from comment #1)

(the service UpdateServiceStub @mozilla.org/updates/update-service-stub;1 does not appear to exist on my Windows artifact build from central this morning; it's not clear to me if that's a new development or has just been broken for longer or what.)

>>> Cc["@mozilla.org/updates/update-service-stub;1"].getService(Ci.nsIApplicationUpdateServiceStub).updateDisabled
false

Not sure why you are missing it. It sure should be there. It is there on Nightly.

Comment 5

[:Gijs (he/him)]

(In reply to Robin Steuber (they/them) [:bytesized] from comment #4)

I'll try to investigate this further as soon as I have the capacity. In the meantime though,

(In reply to :Gijs (he/him) from comment #0)

where the condition is presumably not right?

Not sure what this means?

I mean that the task has a condition: condition: AppConstants.MOZ_UPDATE_AGENT, (and in fact, then some more conditions inside the task itself!) and those check some constants, and so I assume there is some kind of mismatch where whether these conditions pass does not correspond 1:1 to the availability of the service that we're using inside the task.

(In reply to :Gijs (he/him) from comment #1)

(the service UpdateServiceStub @mozilla.org/updates/update-service-stub;1 does not appear to exist on my Windows artifact build from central this morning; it's not clear to me if that's a new development or has just been broken for longer or what.)

>>> Cc["@mozilla.org/updates/update-service-stub;1"].getService(Ci.nsIApplicationUpdateServiceStub).updateDisabled
false

Not sure why you are missing it. It sure should be there. It is there on Nightly.

Are you testing on a local artifact build? It wouldn't surprise me if they have parts of the updater disabled... I'm at a co-working space today, without my Windows machine, so cannot easily retest at the moment - I can check again when back home late tonight or on Monday.

Comment 6

[Robin Steuber (she/her) [:bytesized]]

(In reply to :Gijs (he/him) from comment #5)

Are you testing on a local artifact build? It wouldn't surprise me if they have parts of the updater disabled... I'm at a co-working space today, without my Windows machine, so cannot easily retest at the moment - I can check again when back home late tonight or on Monday.

Well, no. As I said, I was testing on Nightly. I've just tested on an artifact build, and I can indeed reproduce this problem. Curious. The Update Service Stub should definitely be present in this case. It only shouldn't be included if update is disabled or the build target is Android. Since we are experiencing the problem behind a AppConstants.MOZ_UPDATER guard, it isn't that. It seems silly to check that MOZ_WIDGET_TOOLKIT != "android" on a build I'm running on Windows, but I did anyways and the result was what I'd expect.

I'll keep investigating. I feel like I've seen problems similar to this when there is an error loading the relevant mjs module or an error in the service constructor. Perhaps one of those is happening?

Comment 7

[Robin Steuber (she/her) [:bytesized]]

Huh. I was able to reproduce this on an out-of-date local build, but then I updated mozilla-central and now the problem seems to be gone.

@Gijs - Can you still reproduce the problem on an up-to-date checkout of central?

Comment 8

[:Gijs (he/him)]

Hm, interesting - yes, I also can't repro anymore. :-(

I guess this will remain a mystery unless/until it reoccurs.

Comment 9

[Nick Alexander :nalexander [he/him]]

An hg id and a ./mach artifact install -v log on a build that fails would let us narrow this down. This sounds like an artifacts mismatch, which is annoying but (infrequently) expected.