832501 - Sync issues in metro fx

Status: RESOLVED INVALID

(Firefox for Metro Graveyard :: Browser, defect)

Description

[Allison Naaktgeboren :ally]

Attachment: (B)log from master, locking errors

I'm seeing the following error logs show up all the time on my client.

I suspect they are not related, but I am dropping them here. this might turn into a tracking bug.

A)I did a metro-metro pairing and both computers spat out erroring logs (though mostly works), though at least some data appears to be moving between them.

B) there is a series of these on the metro fx from the past 2 weeks. I noticed them when trying to troubleshoot (A)

Comment 1

[Allison Naaktgeboren :ally]

Attachment: (A) Error log from the slave in metro-metro pairing

Comment 2

[Allison Naaktgeboren :ally]

from (A) I suspect this is the issue is with passwords:

1358544838464	Sync.Engine.Passwords	WARN	Got exception Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] Stack trace: resource://gre/modules/services-sync/engines/passwords.js:84 < resource://gre/modules/XPCOMUtils.jsm:177 < applyIncomingBatch()@resource://gre/modules/services-sync/engines/passwords.js:132 < doApplyBatch()@resource://services-sync/engines.js:813 < doApplyBatchAndPersistFailed()@resource://services-sync/engines.js:828 < resource://services-sync/engines.js:932 < SyncEngine__sync()@resource://services-sync/engines.js:1342 < WrappedNotify()@resource://services-sync/util.js:142 < Engine_sync()@resource://services-sync/engines.js:519 < _syncEngine()@resource://gre/modules/services-sync/stages/enginesync.js:192 < sync()@resource://gre/modules/services-sync/stages/enginesync.js:147 < onNotify()@resource://gre/modules/services-sync/service.js:1185 < WrappedNotify()@resource://services-sync/util.js:142 < WrappedLock()@resource://services-sync/util.js:97 < _lockedSync()@resource://gre/modules/services-sync/service.js:1179 < resource://gre/modules/services-sync/service.js:1170 < WrappedCatch()@resource://services-sync/util.js:71 < sync()@resource://gre/modules/services-sync/service.js:1158 < connect/<()@sync.js:328 < <file:unknown>, aborting processIncoming.
1358544838464	Sync.Status	DEBUG	Status for engine passwords: error.engine.reason.unknown_fail
1358544838464	Sync.Status	DEBUG	Status.service: success.status_ok => error.sync.failed_partial
1358544838464	Sync.ErrorHandler	DEBUG	passwords failed: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] Stack trace: resource://gre/modules/services-sync/engines/passwords.js:84 < resource://gre/modules/XPCOMUtils.jsm:177 < applyIncomingBatch()@resource://gre/modules/services-sync/engines/passwords.js:132 < doApplyBatch()@resource://services-sync/engines.js:813 < doApplyBatchAndPersistFailed()@resource://services-sync/engines.js:828 < resource://services-sync/engines.js:932 < SyncEngine__sync()@resource://services-sync/engines.js:1342 < WrappedNotify()@resource://services-sync/util.js:142 < Engine_sync()@resource://services-sync/engines.js:519 < _syncEngine()@resource://gre/modules/services-sync/stages/enginesync.js:192 < sync()@resource://gre/modules/services-sync/stages/enginesync.js:147 < onNotify()@resource://gre/modules/services-sync/service.js:1185 < WrappedNotify()@resource://services-sync/util.js:142 < WrappedLock()@resource://services-sync/util.js:97 < _lockedSync()@resource://gre/modules/services-sync/service.js:1179 < resource://gre/modules/services-sync/service.js:1170 < WrappedCatch()@resource://services-sync/util.js:71 < sync()@resource://gre/modules/services-sync/service.js:1158 < connect/<()@sync.js:328 < <file:unknown>

Comment 3

[Richard Newman [:rnewman]]

If this is based on XUL Fennec, that's probably Bug 686362.

Comment 4

[Richard Newman [:rnewman]]

Locking errors indicate that something died before releasing the sync lock, probably because something wasn't expecting an error, and thus didn't have a catch block to invoke an async callback.

My guess would be that the error is a failed import in a lazy getter, which means some code that looks like an attribute access actually throws.

So let's figure out why nsILoginInfo is different here, and see if the lock problem goes away.

Comment 5

[Richard Newman [:rnewman]]

Ally:

let svc = Components.classes["@mozilla.org/login-manager;1"].getService(Components.interfaces.nsILoginManager);
let item = svc.getAllLogins().pop();
console.log("Is a metainfo? " + (item instanceof Components.interfaces.nsILoginMetaInfo));


should print true. If it doesn't, that'll be what's up :)

Comment 6

[Jim Mathies [:jimm]]

covered by other, more specific bugs.