This is one of the top crasher on Chrome OS and below is the link to the list of the builds:

https://goto.google.com/lihgx

James@: Could you please confirm if https://codereview.chromium.org/2861773003 would fix this as well.

No, my CL won't fix the problem. It only affects chrome --mash, which is a flag not used in production.

It looks like something is accessing a deleted view or style.

mohsen, could this be due to your recent CLs?
https://codereview.chromium.org/2831023003
https://codereview.chromium.org/2843163003

+stevenjb in case he knows about anything odd about networking items in the connecting state.

 Issue 718189  has been merged into this issue.

Do we know the regression starting point?

Maybe it is introduced in https://codereview.chromium.org/2831023003. HoverHighlightView::SetSubText seems having changed the original logic. For wifi entries that are not connecting/connected, sub_text could be empty.

Is it possible to revert this change to unblock dev release? 
we can do that in the dev rc branch 3086, any adverse effect if we revert? 

Re #6, I think at least one CL was landed on top of the CL in #5, so the revert may not be clean. I am looking into a fix.

Oh, I just created a CL that could fix this: https://codereview.chromium.org/2865473002/.

ok, can you also drover to 3086 once CL is reviewed/ready?

Is  Issue 716397  related?

Update: CL in #8 does not look like it will fix the problem. I am in the process of bisecting, and both mohsen@ and warx@ are performing their own parallel investigations.

Re #10 I suspect that is a different issue; I can test it as I bisect though.

As an update to the repro steps, I don't think you need to click on a connecting row to see the crash. I believe the crash will happen whenever we try to show a row with any subtext in the networking detailed view. My repro steps on a local build:

(1) run with: ./out/Default/chrome --shill-stub="wifi=off,eth=0,interactive=3"

(2) go to network menu, click on "wifi2_PSK"

(3) type in any password, click OK

(4) then quickly try to go back to the network menu, it will crash

 Issue 717250  has been merged into this issue.

I think I've found the root cause of the issue. Will upload a fix soon...

Re #10, I am fairly sure that issue is separate from this one. My bisect is still ongoing but as of 6add17253a0318bb3360c33de735f1f0ab3b8cd2 I notice that the crash described here still occurs, but the crash in  issue 716397  does not.

CL uploaded: https://crrev.com/2865533002

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e5f363be8e46b5e650988d7393390940bd25ff67

commit e5f363be8e46b5e650988d7393390940bd25ff67
Author: mohsen <mohsen@chromium.org>
Date: Thu May 04 21:44:44 2017

Reset HoverHighlightView state before re-populating

When a HoverHighlightView needs to be repopulated, other than removing
its children, the pointers it has to its children should be nulled out,
too. Otherwise, it would try to reuse them causing crashes. This CL adds
a Reset() function to HoverHighlightView that properly resets the state
of HoverHighlightView before re-populating it.

BUG= 718411 
TEST=none

Review-Url: https://codereview.chromium.org/2865533002
Cr-Commit-Position: refs/heads/master@{#469480}

[modify] https://crrev.com/e5f363be8e46b5e650988d7393390940bd25ff67/ash/system/network/network_list.cc
[modify] https://crrev.com/e5f363be8e46b5e650988d7393390940bd25ff67/ash/system/network/vpn_list_view.cc
[modify] https://crrev.com/e5f363be8e46b5e650988d7393390940bd25ff67/ash/system/tray/hover_highlight_view.cc
[modify] https://crrev.com/e5f363be8e46b5e650988d7393390940bd25ff67/ash/system/tray/hover_highlight_view.h

@mohsen, can you drover  https://crrev.com/2865533002 into 3086 for dev rc?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5d20b0cede94b6473d61950c4014b125717804b6

commit 5d20b0cede94b6473d61950c4014b125717804b6
Author: Mohsen Izadi <mohsen@chromium.org>
Date: Thu May 04 22:26:15 2017

Reset HoverHighlightView state before re-populating

When a HoverHighlightView needs to be repopulated, other than removing
its children, the pointers it has to its children should be nulled out,
too. Otherwise, it would try to reuse them causing crashes. This CL adds
a Reset() function to HoverHighlightView that properly resets the state
of HoverHighlightView before re-populating it.

BUG= 718411 
TEST=none

Review-Url: https://codereview.chromium.org/2865533002
Cr-Commit-Position: refs/heads/master@{#469480}
(cherry picked from commit e5f363be8e46b5e650988d7393390940bd25ff67)

Review-Url: https://codereview.chromium.org/2863783002 .
Cr-Commit-Position: refs/branch-heads/3086@{#5}
Cr-Branched-From: 4159f36e93c398b9816b734a14e97220e83fc912-refs/heads/master@{#468266}

[modify] https://crrev.com/5d20b0cede94b6473d61950c4014b125717804b6/ash/system/network/network_list.cc
[modify] https://crrev.com/5d20b0cede94b6473d61950c4014b125717804b6/ash/system/network/vpn_list_view.cc
[modify] https://crrev.com/5d20b0cede94b6473d61950c4014b125717804b6/ash/system/tray/hover_highlight_view.cc
[modify] https://crrev.com/5d20b0cede94b6473d61950c4014b125717804b6/ash/system/tray/hover_highlight_view.h

josafat@: Done.

A note about this crash:

It seems that this issue has been existing for a long time. Even if https://crrev.com/2831023003 has not been landed, you would see the crash (in a different location) due to HoverHighlightView::right_view_ pointing to a deleted view. tdanderson@'s bisect also confirms that (see comment #14 which mentions the crash is happening in a more-than-a-month-old revision).

Probably, what has caused the crash to surface recently is a regression in networking code that causes establishing connections to take longer, giving connecting animation enough time to cause the crash. For example, when we ran chrome with --shill-stub="interactive=3" (which means 3 seconds delay until connection is established, the value tdanderson@ was using in his bisect) we saw the crash even before https://crrev.com/2831023003 landed, however, when we used 1 second delay, we couldn't repro the crash even on ToT! That's why I guess something on the networking side has changed.

To summarize:
 * The issue I fixed in r469480 has been a long standing issue.
 * It seems to me that recently something has regressed in the networking code causing establishing connections take longer which is probably worth investigating.

stevenjb@: Does the above analysis make sense?

Hmmm. I haven't noticed this locally. Connect times can vary widely by AP though, and 1 second is pretty quick for a new secure network connection, i.e. taking ~3 seconds to connect to some networks for the first time is not new behavior in my experience.

It seems equally likely that a change in memory allocation or simple code shuffling has made the bug more or less likely to trigger a crash.

+cernekee@ just in case he is aware of any such change in Shill behavior.

> 1 second is pretty quick for a new secure network connection

I agree with this part.

I am not clear on whether  bug 717250  (Chrome UI crash when connecting to a VPN) is still considered to be a special case of this bug.  But I will note that when I see instances of the VPN crash, the Chrome crash happens long before the VPN connects.  It happens within 1 second of clicking on the VPN entry.  Post-Chrome-restart, if I open the system menu, I often see that the VPN is still in the process of connecting.*

* which is especially true when I'm debugging a VPN connection failure due to problems at a lower level of the stack, and so it tries connecting for ~1min before it gives up

Re #20: If "new secure network connections" are those that need the user to enter a password, then the password dialog will close the system menu and the crash won't have an opportunity to happen.

Re #21:  Issue 717250  has a similar stack trace: AnimationProgress() happens and the detailed view clears contents of the network/vpn row to repopulate it with new values which ends up using a pointer to a deleted |sub_text_label_|. I don't see any reason that's a different issue.

Issue is working fine in latest M60# 60.0.3086.3/9517.1.0 dev channel Daisy.

Tested on latest M60# 60.0.3086.3/9517.1.0 dev channel Candy and Minnie as well and this issue is working fine.

 Issue 719150  has been merged into this issue.

Verified on ChromeOS 9532.0.0, 60.0.3092.0