Possibly related: the above-mentioned memory leak is now gone. The browser process is sitting at a healthy 148MB, not the 1400MB it was at before I deleted my profile directory.

The MergeDataAndStartSyncing error sounds a lot like a Linux/GNOME Keyring issue, similar to issue 762697  issue 773253  issue 766738. Some of those bugs have other weird behavior, and it's difficult for me to tell if your earlier symptoms are related or not.

+UI>Browser>Passwords - We're getting more and more Keyring issue reports. It seems like something probably changed that is causing these problems. It'd be great if we understood what. Though I have no idea how to investigate. Do we have documentation somewhere that explains how the Keyring and Chrome are supposed to interact, and common debugging steps should something go wrong?

If bad data was "uploaded" to sync, and you can take an otherwise healthy device with a clean profile and start syncing and then repro some sort of failure, I'd love to investigate. But I don't think that's what's happening.

User guesses are, after all, notoriously unreliable.

I checked with the keyring viewer, and all entries are duplicated 3 times with different `application` values. (Screenshot 1)

A newly created saved password on reddit.com does NOT show up in the keyring viewer.

A newly created saved password on an alternate Chrome profile, though, DOES show up in the keyring viewer (application: chrome-16675112), and with only one copy.

So I'm going to go with your conclusion being correct, that there's something wrong in the chrome<->keyring communications, and it seems to be per-profile?

Deleted: Screenshot_2017-10-11_12-38-57_.png 77.7 KB

	Screenshot_2017-10-11_12-38-57_.png 77.7 KB View Download

+cfroussios as expert on chrome<->keyring communication

I suspect that calls to keyring are failing and it would be nice to know why.

Could you execute chrome with
google-chrome-beta --enable-logging --vmodule=*/os_crypt/*=1,*/password_manager/*=1
then visit chrome:settings/passwords, give it a minute (in case it's slow), close chrome and upload the contents of chrome_debug.log, which is in your user data directory?

"Bad" news... I just got updated to 62.0.3202.52 and the problem is gone. Passwords are loading and saving again.

Here's the first few lines of the debug log, which are the only VERBOSE lines:

[16659:16711:1013/103826.617238:VERBOSE1:key_storage_util_linux.cc(53)] Password storage detected desktop environment: XFCE
[16659:16659:1013/103826.686848:VERBOSE1:key_storage_util_linux.cc(53)] Password storage detected desktop environment: XFCE
[16659:16659:1013/103826.686900:VERBOSE1:password_store_factory.cc(214)] Trying libsecret for password storage.
[16659:16711:1013/103827.541713:VERBOSE1:key_storage_linux.cc(53)] OSCrypt using Libsecret as backend.
[16659:16659:1013/103827.543057:VERBOSE1:password_store_factory.cc(217)] Using libsecret keyring for password storage.
[16659:16659:1013/103828.628723:INFO:CONSOLE(39)] "10/13/2017, 10:38:28 AM - Signed in with API key XXXXXXXXXXXXXXXXXXXXXXXXXX", source: chrome-extension://chlffgpmiacpedhhbkiomidkjlcfhogd/pb.js (39)
[16659:16659:1013/103828.628863:INFO:CONSOLE(39)] "10/13/2017, 10:38:28 AM - Bootstrapping...", source: chrome-extension://chlffgpmiacpedhhbkiomidkjlcfhogd/pb.js (39)
[16659:16659:1013/103828.658911:INFO:CONSOLE(39)] "10/13/2017, 10:38:28 AM - Connecting to server via WebSocket", source: chrome-extension://chlffgpmiacpedhhbkiomidkjlcfhogd/pb.js (39)
[16659:16659:1013/103828.712826:INFO:CONSOLE(39)] "10/13/2017, 10:38:28 AM - Dismissed e2e", source: chrome-extension://chlffgpmiacpedhhbkiomidkjlcfhogd/pb.js (39)
[1:16:1013/103829.029171:ERROR:adm_helpers.cc(62)] Failed to query stereo recording.

followed by a lot more extension log output.

Nothing was logged after the passwords finished loading.

Here's the upgrade log. Not sure if any of these are related to the keyring?

Upgrade: xserver-common:amd64 (2:1.18.4-0ubuntu0.4, 2:1.18.4-0ubuntu0.6), google-chrome-beta:amd64 (62.0.3202.45-1, 62.0.3202.52-1), xserver-xorg-core:amd64 (2:1.18.4-0ubuntu0.4, 2:1.18.4-0ubuntu0.6), gnome-software:amd64 (3.20.5-0ubuntu0.16.04.5, 3.20.5-0ubuntu0.16.04.6), xserver-xorg-legacy:amd64 (2:1.18.4-0ubuntu0.4, 2:1.18.4-0ubuntu0.6), libmirclient-dev:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libmircommon-dev:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libmircookie2:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libmircore1:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libmircore-dev:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libwayland-client0:amd64 (1.12.0-1~ubuntu16.04.1, 1.12.0-1~ubuntu16.04.2), libwayland-bin:amd64 (1.12.0-1~ubuntu16.04.1, 1.12.0-1~ubuntu16.04.2), x11proto-core-dev:amd64 (7.0.31-1~ubuntu16.04.1, 7.0.31-1~ubuntu16.04.2), libwayland-dev:amd64 (1.12.0-1~ubuntu16.04.1, 1.12.0-1~ubuntu16.04.2), libmirprotobuf3:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libmirclient9:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libmircookie-dev:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), gnome-software-common:amd64 (3.20.5-0ubuntu0.16.04.5, 3.20.5-0ubuntu0.16.04.6), libmircommon7:amd64 (0.26.3+16.04.20170605-0ubuntu1, 0.26.3+16.04.20170605-0ubuntu1.1), libwayland-server0:amd64 (1.12.0-1~ubuntu16.04.1, 1.12.0-1~ubuntu16.04.2), libwayland-cursor0:amd64 (1.12.0-1~ubuntu16.04.1, 1.12.0-1~ubuntu16.04.2)

kanepyork@ Since this issue is not seen on chrome latest beta #62.0.3202.52 can we close this issue?

Could you please check the same on chrome latest dev build and reply to this comment.
https://www.chromium.org/getting-involved/dev-channel

Thanks!

Thanks for the report and updates.

Based on #6 I'm closing this, because Chrome is reported working again. If it breaks or of cfroussios@ wants to probe more into the problem in case it could return, feel free to re-open (or e-mail me to let me know).