If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"Sync encountered an error while syncing: Unknown error.", with "tabs failed: resp.obj is null"

NEW
Unassigned

Status

Cloud Services
Firefox Sync: Backend
7 years ago
6 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 518196 [details]
sync log snippet

Just had two sync failures in a row.  Checked about:sync-log after the second failure -- I'm attaching the log since the last "Starting sync" before the exception.

Note these lines in particular (these are the failures):
1299711399137	Service.Main	DEBUG	history failed: resp.obj is null JS Stack trace: ("all")@engines.js:881 < innerBind("all")@util.js:1449 < SyncEngine__uploadOutgoing()@engines.js:917 < SyncEngine__sync()@engines.js:968 < wrappedSync(null)@util.js:193 < batchedSync()@util.js:199 < WrappedNotify()@util.js:172 < Engine_sync()@engines.js:377 < WeaveSvc__syncEngine([object Object])@service.js:1913 < ()@service.js:1793 < WrappedNotify()@util.js:172 < WrappedLock()@util.js:140 < _lockedSync()@service.js:1695 < ()@service.js:1686 < WrappedCatch()@util.js:114 < sync()@service.js:1667 < (6)@browser.js:5317

and

1299711432115	Service.Main	DEBUG	tabs failed: resp.obj is null JS Stack trace: ("all")@engines.js:881 < innerBind("all")@util.js:1449 < SyncEngine__uploadOutgoing()@engines.js:917 < SyncEngine__sync()@engines.js:968 < WrappedNotify()@util.js:172 < Engine_sync()@engines.js:377 < WeaveSvc__syncEngine([object Object])@service.js:1913 < ()@service.js:1793 < WrappedNotify()@util.js:172 < WrappedLock()@util.js:140 < _lockedSync()@service.js:1695 < ()@service.js:1686 < WrappedCatch()@util.js:114 < sync()@service.js:1667 < (6)@browser.js:5317

I'm running the latest mozilla-central nightly:
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre
(Reporter)

Comment 1

7 years ago
The subsequent sync completed successfully, FWIW.
Same issue here, Aurora 6.0a2 (2011-06-11)

1307913469506	Service.Main	DEBUG	tabs failed: resp.obj is null JS Stack trace: ("all")@engines.js:932 < innerBind("all")@util.js:1180 < SyncEngine__uploadOutgoing()@engines.js:968 < SyncEngine__sync()@engines.js:1019 < WrappedNotify()@util.js:169 < Engine_sync()@engines.js:390 < WeaveSvc__syncEngine([object Object])@service.js:1953 < ()@service.js:1833 < WrappedNotify()@util.js:169 < WrappedLock()@util.js:137 < _lockedSync()@service.js:1735 < ()@service.js:1726 < WrappedCatch()@util.js:111 < sync(false)@service.js:1707 < ([object Object])@service.js:594 < notify([object XPCWrappedNative_NoHelper])@util.js:1011
For log correlation, ntp is working on my machine, and my source IP was 75.101.22.205
(In reply to comment #3)
> For log correlation, ntp is working on my machine, and my source IP was
> 75.101.22.205

Well, the HTTP log doesn't look suspicious. (Thanks atoll!) The request in question had a 65-byte response, just like every other (but one) POST to tabs:

10.10.14.200 - zandr [12/Jun/2011:13:17:53 -0700] "POST /1.1/zandr/storage/tabs HTTP/1.1" 200 65

There are 31 identical such requests in a 3-hour range.

At this point the trail pretty much runs cold. Thinking caps on...
Blocks: 696137
You need to log in before you can comment on or make changes to this bug.