Below are the few other Crash ids from different devices:

bfd2e65e80000000
82b0ad9e80000000
f046ed9e80000000

Though the stack trace is completely diff from  Issue 718411 (fixed on 60.0.3086.3/9517.1.0) but based on somewhat similar manual repro scenario cc'ing mohsen@ for more inputs.

yeah, stack trace is different but it appears to be related to the change landed for  issue 718411  since this crash was not in 3086.0 and the only change was the fix for above bug 
https://chromium.googlesource.com/chromium/src/+log/60.0.3086.0..60.0.3086.3?pretty=fuller&n=10000

mohsen@ can you evaluate?

Removing Blink>Network which is about web APIs (XHR, WebSocket, etc.)

That doesn't seem related to my UI change, rather looks like an issue in the networking stack. The reason you weren't seeing this crash before my change is, probably, that the crash I fixed didn't let the code reach this crash! Now the first crash is not happening, so you see the second one.

I can reproduce this and strangely I am getting the same error as we have been seeing in 714547:

"D-Bus connection was disconnected. Aborting."

That is preceeded by a "SetProperties: Failed: Config.SetProperties Failed" error, which is expected.

So I don't think this is related to any of the status area changes, but rather some change is causing certain types of DBus errors to trigger this CHECK:

https://cs.chromium.org/chromium/src/dbus/bus.cc?q=bus.cc+package:%5Echromium$&dr&l=1189

Yeah, this reminds me of issue 714547 too.

Cc-ing some people who might have ideas about how other D-Bus errors could trigger a (bogus?) "Disconnected" error.

I can reproduce this in chrome @3086.0 (#468250).

So, either this is due to a cros change, or it is from an older chrome change and has not been reported.

Also reproducible at chrome @3085.0 (#468217).

Looking at where this is failing, it seems like it might be a symptom of a more serious dbus failure related to a chromeos change?

Can we confirm where this crash was introduced? If the system tray crashes are getting in the way of the password dialog showing, it should be possible to trigger the dialog from the Settings UI instead.

Well, the system tray crash ( issue 718411 ) should not happen before password dialog. They happen during the connecting animation. The password dialog closes the system tray, so no animation should be kicked off unless the system menu is re-opened while connecting. So, those crashes should not interfer with this one and last part of my comment in #6 is not valid!

https://codereview.chromium.org/2808983002/ could be related? does this issue reproduce with the change reverted locally?

That was the first thing I tried :) Didn't help.

I've just commented here crbug.com/714547#c14 but I'm guessing that issue 714547 and this issue are a reappearance of  issue 181655 .  The stack trace at #c10 also included dbus::Bus::OnConnectionDisconnected() and dbus::Bus::OnConnectionDisconnectedFilter ().

In short, empty object paths somehow caused Chrome getting "disconnected" signal. The fix at that time was to remove --disable-check from dbus's build config.

https://chromium-review.googlesource.com/c/45545/5/sys-apps/dbus/dbus-1.6.8-r2.ebuild

Ah, and it looks like we recently updated the dbus version to 1.10.12 :

https://chromium-review.googlesource.com/c/461717/

Can we try removing that flag in the updated ebuild?

Can we add PRESUBMIT check or something to prevent --disable-check (now --disable-checks?) from getting added again?

Forgot to mention but passing empty object paths sounds like a bug. We should investigate where these come from and fix these.

I don't have a particular reason for why I added back the --disable-checks flag during the dbus upgrade, probably just copied from gentoo upstream.

The CL that removed it long ago was saying, "Let me remove this flag until fixing the actual root cause", so is the real bug still alive?

Anyways, I don't have an objection of removing it again. Just that I might not be the best person to properly test it though - only work on chromium os occasionally.

Apparently --disable-checks came from upstream ebuild.
https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/dbus/dbus-1.10.12.ebuild

If the empty object path is the root cause and the sender is using libchrome's D-Bus library, we can add a CHECK in dbus::MessageWriter to prevent sending empty ObjectPath.

Made a CL to remove --disable-checks.
https://chromium-review.googlesource.com/c/499967/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/4afb4364174e7491eddd6cf757f35446acacd8c7

commit 4afb4364174e7491eddd6cf757f35446acacd8c7
Author: Ryo Hashimoto <hashimoto@google.com>
Date: Thu May 11 03:58:08 2017

sys-apps/dbus: Remove --disable-check

Building dbus with --disable-check results in mysterious behaviors when
invalid values (e.g. empty object path) are sent on D-Bus.

BUG= chromium:718814 
TEST=emerge-$BOARD dbus

Change-Id: I53572b0d238279afb9289a19d1c60e3f2e77bbf0
Reviewed-on: https://chromium-review.googlesource.com/499967
Commit-Ready: Ryo Hashimoto <hashimoto@chromium.org>
Tested-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Satoru Takabayashi <satorux@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/4afb4364174e7491eddd6cf757f35446acacd8c7/sys-apps/dbus/dbus-1.10.12.ebuild
[rename] https://crrev.com/4afb4364174e7491eddd6cf757f35446acacd8c7/sys-apps/dbus/dbus-1.10.12-r2.ebuild

Now we are no longer using --disable-check when building dbus, so invalid values like empty object paths don't result in mysterious behavior like chrome crash.

Steven, is it possible to locate the actual code which is sending invalid values with D-Bus (e.g. empty object paths, non-UTF8 strings)?
Crash should be gone, but we may end up repeating this again when uprevving libdbus in future.

I don't know a good way to identify that off the top of my head. I didn't see any indication that Chrome was sending bad info when I investigated this, so I wonder if it was caused by Shill sending empty object paths in a response when an error occurred (but I'm not at all certain that was the case).

I think we should resolve this bug is fixed and maybe file a separate bug to investigate that?

OK, filed issue 721668 for investigation.

We shouldn't see this crash no longer, closing as fixed.

No crash observed on 9563.0.0, 60.0.3102.0 with repro steps in bug description.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/005ac9903d0e8cd98281496f48bc1b3296b3769b

commit 005ac9903d0e8cd98281496f48bc1b3296b3769b
Author: Ryo Hashimoto <hashimoto@google.com>
Date: Wed Jun 28 10:09:52 2017

sys-apps/dbus: Add a presubmit check against --disable-checks

With --disable-checks, dbus daemon behaves in an unpredictable way.
We should avoid adding this again when uprevving dbus.

BUG= chromium:718814 
TEST=repo upload

Change-Id: Ic84be1c6428243e84b5f55685e601f50f573796c
Reviewed-on: https://chromium-review.googlesource.com/505790
Commit-Ready: Ryo Hashimoto <hashimoto@chromium.org>
Tested-by: Ryo Hashimoto <hashimoto@chromium.org>
Reviewed-by: Ben Chan <benchan@chromium.org>

[add] https://crrev.com/005ac9903d0e8cd98281496f48bc1b3296b3769b/sys-apps/dbus/presubmit_check.sh
[modify] https://crrev.com/005ac9903d0e8cd98281496f48bc1b3296b3769b/PRESUBMIT.cfg