1190131 - Sync fails on new device: creating livemark failed: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAnnotationService.setItemAnnotation]"

Status: VERIFIED FIXED

(Firefox :: Sync, defect, P1)

Description

[Gregory Szorc [:gps]]

I did a fresh install of Windows 10, installed Nightly, signed into my Firefox account, and sync is persistently failing to sync bookmarks. I have tons of sync error logs all containing the same pattern:

1438480697406	Sync.Engine.Bookmarks	INFO	0 outgoing items pre-reconciliation
1438480697407	Sync.BrowserIDManager	DEBUG	_ensureValidToken already has one
1438480697413	Sync.Engine.Bookmarks	ERROR	null
1438480697645	Sync.Store.Bookmarks	DEBUG	Applying record SBWTkBwympi4
1438480697646	Sync.Store.Bookmarks	DEBUG	Local parent is toolbar
1438480697646	Sync.Store.Bookmarks	DEBUG	Record SBWTkBwympi4 is not an orphan.
1438480697646	Sync.Store.Bookmarks	DEBUG	Local record and remote record differ in type. Deleting and recreating.
1438480697646	Sync.Store.Bookmarks	DEBUG	  -> removing folder SBWTkBwympi4
1438480697657	Sync.Store.Bookmarks	ERROR	creating livemark failed: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAnnotationService.setItemAnnotation]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/components/nsLivemarkService.js :: writeFeedURI :: line 466"  data: no]
1438480697657	Sync.Store.Bookmarks	WARN	Failed to apply incoming record SBWTkBwympi4
1438480697657	Sync.Store.Bookmarks	WARN	Encountered exception: 2147549183 No traceback available
1438480697659	Sync.Store.Bookmarks	DEBUG	Applying record bvG6-X6aLLt6
1438480697659	Sync.Store.Bookmarks	DEBUG	Local parent is toolbar
1438480697659	Sync.Store.Bookmarks	DEBUG	Record bvG6-X6aLLt6 is not an orphan.
1438480697660	Sync.Store.Bookmarks	DEBUG	Local record and remote record differ in type. Deleting and recreating.
1438480697660	Sync.Store.Bookmarks	DEBUG	  -> removing folder bvG6-X6aLLt6
1438480697670	Sync.Store.Bookmarks	ERROR	creating livemark failed: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAnnotationService.setItemAnnotation]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/components/nsLivemarkService.js :: writeFeedURI :: line 466"  data: no]
1438480697670	Sync.Store.Bookmarks	WARN	Failed to apply incoming record bvG6-X6aLLt6
1438480697670	Sync.Store.Bookmarks	WARN	Encountered exception: 2147549183 No traceback available
1438480697672	Sync.Store.Bookmarks	DEBUG	Applying record mMv_kYtzZPGI
1438480697672	Sync.Store.Bookmarks	DEBUG	Local parent is toolbar
1438480697672	Sync.Store.Bookmarks	DEBUG	Record mMv_kYtzZPGI is not an orphan.
1438480697673	Sync.Store.Bookmarks	DEBUG	Local record and remote record differ in type. Deleting and recreating.
1438480697673	Sync.Store.Bookmarks	DEBUG	  -> removing folder mMv_kYtzZPGI
1438480697680	Sync.Store.Bookmarks	ERROR	creating livemark failed: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAnnotationService.setItemAnnotation]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/components/nsLivemarkService.js :: writeFeedURI :: line 466"  data: no]
1438480697680	Sync.Store.Bookmarks	WARN	Failed to apply incoming record mMv_kYtzZPGI
1438480697680	Sync.Store.Bookmarks	WARN	Encountered exception: 2147549183 No traceback available
1438480697680	Sync.Collection	DEBUG	mesg: GET success 200 https://sync-235-us-west-2.sync.services.mozilla.com/1.5/25582663/storage/bookmarks?full=1&sort=index&ids=SBWTkBwympi4,bvG6-X6aLLt6,mMv_kYtzZPGI
1438480697680	Sync.Collection	DEBUG	GET success 200 https://sync-235-us-west-2.sync.services.mozilla.com/1.5/25582663/storage/bookmarks?full=1&sort=index&ids=SBWTkBwympi4,bvG6-X6aLLt6,mMv_kYtzZPGI
1438480697681	Sync.Engine.Bookmarks	DEBUG	Records that failed to apply: SBWTkBwympi4,bvG6-X6aLLt6,mMv_kYtzZPGI
1438480697681	Sync.Engine.Bookmarks	INFO	Records: 3 applied, 0 successfully, 3 failed to apply, 0 newly failed to apply, 0 reconciled.

Most of my bookmarks did sync. It's just these few records that don't apply.

Let me crank up the logging so I can get the raw records that are failing to apply...

Comment 1

[Gregory Szorc [:gps]]

Here's 2 of my 3 failures. The 3rd is somewhat embarrassing so I've omitted it :)

1438481107846	Sync.Engine.Bookmarks	TRACE	Incoming: { id: bvG6-X6aLLt6  index: 150  modified: 1437453412.63  ttl: undefined  payload: {"id":"bvG6-X6aLLt6","type":"livemark","feedUri":"http://en-us.fxfeeds.mozilla.com/en-US/firefox/headlines.xml","siteUri":"http://www.bbc.co.uk/go/rss/int/news/-/news/","parentName":"Bookmarks Toolbar","title":"Latest Headlines","description":null,"children":[],"parentid":"toolbar"}  collection: bookmarks }
1438481107847	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID bvG6-X6aLLt6: 1
1438481107847	Sync.Engine.Bookmarks	TRACE	Reconciling bvG6-X6aLLt6. exists=true; modified=false; local age=null; incoming age=1027694.8099999428
1438481107847	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID bvG6-X6aLLt6: 1
1438481107848	Sync.Engine.Bookmarks	TRACE	Finding mapping: Bookmarks Toolbar, fLatest Headlines
1438481107848	Sync.Engine.Bookmarks	TRACE	Mapped dupe: bvG6-X6aLLt6
1438481107848	Sync.Engine.Bookmarks	TRACE	Applying incoming record because no local conflicts.
1438481107848	Sync.Store.Bookmarks	DEBUG	Applying record bvG6-X6aLLt6
1438481107848	Sync.Store.Bookmarks	DEBUG	Local parent is toolbar
1438481107848	Sync.Store.Bookmarks	DEBUG	Record bvG6-X6aLLt6 is not an orphan.
1438481107848	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID bvG6-X6aLLt6: 1
1438481107848	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID bvG6-X6aLLt6: 1
1438481107848	Sync.Store.Bookmarks	TRACE	Local type: folder. Remote type: livemark.
1438481107848	Sync.Store.Bookmarks	DEBUG	Local record and remote record differ in type. Deleting and recreating.
1438481107848	Sync.Store.Bookmarks	DEBUG	  -> removing folder bvG6-X6aLLt6
1438481107860	Sync.Store.Bookmarks	ERROR	creating livemark failed: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAnnotationService.setItemAnnotation]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/components/nsLivemarkService.js :: writeFeedURI :: line 466"  data: no]
1438481107860	Sync.Store.Bookmarks	WARN	Failed to apply incoming record bvG6-X6aLLt6
1438481107860	Sync.Store.Bookmarks	WARN	Encountered exception: 2147549183 No traceback available
1438481107861	Sync.Engine.Bookmarks	TRACE	Incoming: { id: mMv_kYtzZPGI  index: 150  modified: 1437255350.9  ttl: undefined  payload: {"id":"mMv_kYtzZPGI","type":"livemark","feedUri":"http://research.microsoft.com/en-us/um/redmond/projects/kinectsdk/kdkrss.xml","siteUri":"http://blogs.msdn.com/b/kinectforwindows/","parentName":"Bookmarks Toolbar","title":"Microsoft Research Kinect for Windows SDK","description":null,"children":[],"parentid":"toolbar"}  collection: bookmarks }
1438481107862	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID mMv_kYtzZPGI: 1
1438481107862	Sync.Engine.Bookmarks	TRACE	Reconciling mMv_kYtzZPGI. exists=true; modified=false; local age=null; incoming age=1225756.5399999619
1438481107862	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID mMv_kYtzZPGI: 1
1438481107862	Sync.Engine.Bookmarks	TRACE	Finding mapping: Bookmarks Toolbar, fMicrosoft Research Kinect for Windows SDK
1438481107862	Sync.Engine.Bookmarks	TRACE	Mapped dupe: mMv_kYtzZPGI
1438481107863	Sync.Engine.Bookmarks	TRACE	Applying incoming record because no local conflicts.
1438481107863	Sync.Store.Bookmarks	DEBUG	Applying record mMv_kYtzZPGI
1438481107863	Sync.Store.Bookmarks	DEBUG	Local parent is toolbar
1438481107863	Sync.Store.Bookmarks	DEBUG	Record mMv_kYtzZPGI is not an orphan.
1438481107863	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID mMv_kYtzZPGI: 1
1438481107863	Sync.Store.Bookmarks	TRACE	Number of rows matching GUID mMv_kYtzZPGI: 1
1438481107863	Sync.Store.Bookmarks	TRACE	Local type: folder. Remote type: livemark.
1438481107863	Sync.Store.Bookmarks	DEBUG	Local record and remote record differ in type. Deleting and recreating.
1438481107863	Sync.Store.Bookmarks	DEBUG	  -> removing folder mMv_kYtzZPGI
1438481107871	Sync.Store.Bookmarks	ERROR	creating livemark failed: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAnnotationService.setItemAnnotation]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/components/nsLivemarkService.js :: writeFeedURI :: line 466"  data: no]
1438481107871	Sync.Store.Bookmarks	WARN	Failed to apply incoming record mMv_kYtzZPGI
1438481107871	Sync.Store.Bookmarks	WARN	Encountered exception: 2147549183 No traceback available

Comment 2

[Gregory Szorc [:gps]]

FWIW, I discovered this bug because Whimsy Pro makes a sound effect when bookmarks are created and the sound effect kept playing every few minutes, despite me not bookmarking anything. I'm sure bwinton would be amused.

Comment 3

[Richard Newman [:rnewman]]

> Local record and remote record differ in type. Deleting and recreating.

implies that we are indeed going into a loop of creating a folder and failing to annotate it as a livemark.

This failure means that

  PlacesUtils.livemarks.addLivemark(livemarkObj)

is rejecting. livemarkObj is:

      let livemarkObj = {title: record.title,
                         parentId: record._parent,
                         index: PlacesUtils.bookmarks.DEFAULT_INDEX,
                         feedURI: Utils.makeURI(record.feedUri),
                         siteURI: siteURI,
                         guid: record.id};


Marco, is this a Places bug?

Comment 4

[Marco Bonardo [:mak]]

There are only 2 values passed to setItemAnnotation, the uri and the item id.
Supposing the uri can't be invalid, since it comes from an nsIURI, the only thing left is the item id.

I don't know how the item id might be invalid, since we just created the bookmark folder, I might only guess the guids cache goes out of sync for some reason.
I can't tell off-hand if this is a Places bug, from what I see something makes Places try to insert an annotation to an invalid id and this properly throws. That id comes from PlacesUtils.promiseItemId, that makes me think the cache has the guid pointing to an invalid id. We had bug 1012597, but with that fixed I can't tell why that may happen (unless the fix didn't cover the whole thing).

When the error happens might be interesting to know the result of
let id = yield PlacesUtils.promiseItemId(INCOMING_GUID); (the guid that Sync is trying to apply)
and check if that id exists in moz_bookmarks:
PlacesUtils.bookmarks.getItemTitle(id);

if this throws, that means the id doesn't exist, thus something confused the cache.

Comment 5

[Richard Newman [:rnewman]]

Greg, do you have time to look at this yourself?

Comment 6

[Mark Hammond [:markh] [:mhammond]]

(In reply to Marco Bonardo [::mak] (spotty available until 24 Aug) from comment #4)
> I don't know how the item id might be invalid, since we just created the
> bookmark folder, I might only guess the guids cache goes out of sync for
> some reason.

FWIW, I just filed bug 1192692, in which we can see that the use of promiseBookmarksTree() causes the cache to get out of date. Sync indirectly calls this on a first sync for a device, so this may be the cause of some strangeness, but it's not clear if it is the cause of *this* strangeness.

Comment 7

[Gregory Szorc [:gps]]

I'm pretty busy this week. There's a chance I can get to this next week.

Comment 8

[Mark Hammond [:markh] [:mhammond]]

I can reliably reproduce this - but can't understand it.

First sync on a new profile gets an error:

1439871388737	Sync.Store.Bookmarks	ERROR	creating livemark failed: Error: no item found for the given GUID (resource://gre/modules/PlacesUtils.jsm:2425:1)

Which bizarrely comes from https://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/Bookmarks.jsm#177 - which is failure to find the id for a bookmark we just added! Immediately after this failure I can shut Firefox down and SQLManager shows the record does infact exist. Subsequent syncs then fail with the exception described above:

1439879486183	Sync.Store.Bookmarks	ERROR	creating livemark failed: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIAnnotationService.setItemAnnotation]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: file:///o:/src/mozilla-git/gecko-dev/obj-release/dist/bin/components/nsLivemarkService.js :: writeFeedURI :: line 475"  data: no] Stack trace: writeFeedURI()@nsLivemarkService.js:475 < addLivemark/<()@nsLivemarkService.js:238 < InterpretGeneratorResume()@self-hosted:807 < next()@self-hosted:715 < TaskImpl_run()@resource://gre/modules/Task.jsm:314 < Handler.prototype.process()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:934 < this.PromiseWalker.walkerLoop()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:813 < <file:unknown>

which is the annotation service failing as it can't find the item id. The end result is that my profile ends up with non-functioning live-marks. I can reproduce this reliably by starting with new profiles.

Mak, any ideas on how this could possibly happen?

Comment 9

[Mark Hammond [:markh] [:mhammond]]

The issue is caused by Sync wrapping a bookmarks Sync with PlacesUtils.bookmarks.runInBatchMode(). This creates a transaction from C code (IIUC). When insertBookmark() in Bookmarks.jsm calls db.executeTransaction(), we end up in the catch handler https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/Sqlite.jsm#568 when attempting to start the transaction and silently continue due to this "outer c++ created" transaction.

IOW, in this case, when db.executeTransaction() returns the transaction is *not* committed - and because insertBookmark() uses PlacesUtils.withConnectionWrapper() and GuidHelper() uses PlacesUtils.promiseDBConnection(), we have 2 different connections being used, so the lack of the commit explains why https://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/Bookmarks.jsm#177 is failing to find the ID for the bookmark it just created.

Everything works correctly when I omit the runInBatchMode() call, but as rnewman pointed out in IRC, that doesn't seem like the correct approach due to the perf impact it will have. On the other hand though, places now seems to be relying on "internal" transactions (eg, insertBookmark() uses one) and given Sqlite.jsm explicitly forbids nested transactions, I'm confused how we should proceed here.  runInBatchMode seems fundamentally incompatible with async operations, but there doesn't seem to be an equivalent mechanism that isn't.

Mak, I'd welcome any insights here - there are a number of potential bugs I can see in the above. While my main concern is to get livemarks working correctly I fear there are more demons in the shadows (eg, the bug above is actually about *all* bookmark creation and not specific to livemarks, it's just that Sync doesn't seem to be using the problematic methods for "normal" bookmarks - but what other code paths will have this issue that we are yet to identify?

Comment 10

[Mark Hammond [:markh] [:mhammond]]

FTR, I just timed a full bookmarks sync using one of my test accounts with 10,000 bookmarks. With runInBatchMode the bookmarks took 210s to apply and without it took 285s - a significant difference but smaller than I expected.

Comment 13

[Marco Bonardo [:mak]]

(In reply to Mark Hammond [:markh] from comment #9)
> The issue is caused by Sync wrapping a bookmarks Sync with
> PlacesUtils.bookmarks.runInBatchMode(). This creates a transaction from C
> code (IIUC).

batches have 2 effects:
1. wrap queries in a transaction. This is generally faster, but with WAL journal the advantage is smaller than it was in the past.
2. notify listeners a huge amount of changes is incoming. This is used in the UI views to avoid repeated updates when many updates may happen in a row.

We don't have a well defined story for batches in async APIs, we were evaluating to attack that problem once we were converting consumers to Bookmarks.jsm, before the project suddenly paused.

When insertBookmark() in Bookmarks.jsm calls
> db.executeTransaction(), we end up in the catch handler
> https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/Sqlite.
> jsm#568 when attempting to start the transaction and silently continue due
> to this "outer c++ created" transaction.

yes, Sqlite doesn't allow to nest transactions, unless you use SAVEPOINTs, but since we cannot mixup savepoints and transactions and we use transactions, we never moved to savepoints.

> IOW, in this case, when db.executeTransaction() returns the transaction is
> *not* committed - and because insertBookmark() uses
> PlacesUtils.withConnectionWrapper() and GuidHelper() uses
> PlacesUtils.promiseDBConnection(), we have 2 different connections being
> used, so the lack of the commit explains why
> https://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/
> Bookmarks.jsm#177 is failing to find the ID for the bookmark it just created.

Well sort-of. The connection where the transaction is open would see the change, but any other connection cannot see i, since as you said it's not committed yet. PromiseDBConnection returns a read-only connection that can only see committed changes.

> runInBatchMode seems fundamentally incompatible with
> async operations, but there doesn't seem to be an equivalent mechanism that
> isn't.

It's a grey area, technically there's nothing disallowing them to work together, but there are edge cases, like this one, where it's not great. It's also hard to get it right with 2 bookmarks API! I hope the async bookmarks work can be concluded "soon", so we can go back on the design part and figure out the batches problem.

> Mak, I'd welcome any insights here - there are a number of potential bugs I
> can see in the above.

As I said we are in a grey area, there are many things that could mis-work, but it's also true most of them are not critical. I think the most important thing right now is getting ids/guids right, cause it's the base for anything else.

The quick and raw hack I can suggest we could take and uplift, would be to make the GuidHelper use withConnectionWrapper() instead of promiseDBConnection, this way it should be able to see any ongoing change.

Comment 14

[Mark Hammond [:markh] [:mhammond]]

Attachment: 0001-Bug-1190131-have-GuidHelper-use-withConnectionWrappe.patch

> The quick and raw hack I can suggest we could take and uplift, would be to make
> the GuidHelper use withConnectionWrapper() instead of promiseDBConnection, this
> way it should be able to see any ongoing change.

Cool - something like this?

Comment 15

[Marco Bonardo [:mak]]

Comment on attachment 8653841 [details] [diff] [review]
0001-Bug-1190131-have-GuidHelper-use-withConnectionWrappe.patch

Review of attachment 8653841 [details] [diff] [review]:
-----------------------------------------------------------------

WFM provided you get a green Try run and the new test is actually testing the APIs you are modifying...

::: toolkit/components/places/tests/unit/test_async_in_batchmode.js
@@ +2,5 @@
> +// Sync does runInBatchMode() and before the callback returns the Places async
> +// APIs are used (either by Sync itself, or by any other code in the system)
> +// As seen in bug 1197856 and bug 1190131.
> +
> +Cu.import("resource://gre/modules/PlacesUtils.jsm");

not needed, head_common.js does this

@@ +9,5 @@
> +// loop.
> +function waitForPromise(promise) {
> +  let thread = Cc["@mozilla.org/thread-manager;1"].getService().currentThread;
> +
> +  let finalResult, finalException;

nit: remove newline above

@@ +36,5 @@
> +                   type: PlacesUtils.bookmarks.TYPE_BOOKMARK,
> +                   url: "http://example.com/" };
> +      let insertPromise = PlacesUtils.bookmarks.insert(info);
> +      let bookmark = waitForPromise(insertPromise);
> +      equal(bookmark.url, info.url);

is this test enough to check it is working?
I actually thought you wanted to check promiseItemId and promiseItemGuid before exiting the batch...

Comment 16

[Mark Hammond [:markh] [:mhammond]]

(In reply to Marco Bonardo [::mak] from comment #15)

> is this test enough to check it is working?
> I actually thought you wanted to check promiseItemId and promiseItemGuid
> before exiting the batch...

The check isn't necessary - the test is really just ensuring we don't fail - without the placesutils change the test fails with "Error: no item found for the given GUID".

Comment 17

[Marco Bonardo [:mak]]

(In reply to Mark Hammond [:markh] from comment #16)
> The check isn't necessary - the test is really just ensuring we don't fail -
> without the placesutils change the test fails with "Error: no item found for
> the given GUID".

ah it's likely because Bookmarks.jsm internally uses promiseItemId... but I'd prefer to make that even more explicit, adding it also in the test itself.

Comment 18

[Mark Hammond [:markh] [:mhammond]]

(In reply to Marco Bonardo [::mak] from comment #17)
> ah it's likely because Bookmarks.jsm internally uses promiseItemId... 

It's exactly because of that - that's the entire point :)

> but
> I'd prefer to make that even more explicit, adding it also in the test
> itself.

I don't mind adding the check but the point is that a bookmark can't be created in the first place.

Comment 19

[Marco Bonardo [:mak]]

let's land and uplift this asap, it's quite important.

Comment 20

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/a0e2292b3f08

Comment 21

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a0e2292b3f08

Comment 22

[Marco Bonardo [:mak]]

Comment on attachment 8653841 [details] [diff] [review]
0001-Bug-1190131-have-GuidHelper-use-withConnectionWrappe.patch

Approval Request Comment
[Feature/regressing bug #]: async bookmarks APIs
[User impact if declined]: bookmarks cannot be created during a sync
[Describe test coverage new/current, TreeHerder]: nightly, unit test
[Risks and why]: this is just changing the used database connection, should be safe enough
[String/UUID change made/needed]: none

Comment 23

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Gregory, Mark, the fix for this issue was checked into Nightly yesterday. Would you be able to verify the fix on the latest Nightly 09-01 (tonight's)? This would give me a lot more confidence uplifting the patch to Beta41. Many thanks!

Comment 24

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8653841 [details] [diff] [review]
0001-Bug-1190131-have-GuidHelper-use-withConnectionWrappe.patch

I think this is a key scenario for win10 users. I have requested a few folks to verify the fix on Nightly. In addition, before taking this to Beta41, let's stabilize it on Aurora42 for a day or two.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/40a77893341e

Comment 26

[Mark Hammond [:markh] [:mhammond]]

(In reply to Ritu Kothari (:ritu) from comment #23)
> Gregory, Mark, the fix for this issue was checked into Nightly yesterday.
> Would you be able to verify the fix on the latest Nightly 09-01 (tonight's)?
> This would give me a lot more confidence uplifting the patch to Beta41. Many
> thanks!

I can confirm that I can reproduce the problem on Beta but no longer can on Nightly.

Comment 27

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Thanks Mark! Updating status to verified based on comment 26.

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8653841 [details] [diff] [review]
0001-Bug-1190131-have-GuidHelper-use-withConnectionWrappe.patch

Given that the fix was verified, it seems like a good idea to uplift to Beta41.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/42fd27f8ee22

Comment 31

[Gregory Szorc [:gps]]

The machine encountering the original problem is happy now, presumably due to this fix.