1. Reveman did have a first stab at logs:
==========================================

It crashes in:

UserSwitchAnimatorChromeOS::UserSwitchAnimatorChromeOS

Looks like we might end up with a null window reference somehow.

Example crash report:

https://crash.corp.google.com/browse?stbtiq=aaf7f713b37e0e6e#0

The cause is most likely that one of the Crostini windows did went away without properly disengaging from the system.

2. Looking at it myself I can see...

this callstack:

0x00005b965e2c62a0	(chrome -vector:1471 )	UserSwitchAnimatorChromeOS::UserSwitchAnimatorChromeOS(MultiUserWindowManagerChromeOS*, AccountId const&, int)
0x00005b965e2c4652	(chrome -multi_user_window_manager_chromeos.cc:398 )	MultiUserWindowManagerChromeOS::ActiveUserChanged(user_manager::User const*)
0x00005b965c773b50	(chrome -user_manager_base.cc:1048 )	user_manager::UserManagerBase::NotifyActiveUserChanged(user_manager::User const*)
0x00005b965c7737ae	(chrome -user_manager_base.cc:281 )	user_manager::UserManagerBase::SwitchActiveUser(AccountId const&)
0x00005b96592376fe	(chrome -callback.h:96 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x00005b9659238c49	(chrome -incoming_task_queue.cc:124 )	base::MessageLoop::RunTask(base::PendingTask*)
0x00005b9659239508	(chrome -message_loop.cc:329 )	base::MessageLoop::DoWork()
0x00005b9659242407	(chrome -message_pump_libevent.cc:210 )	base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)
0x00005b965b64e4ea	(chrome -run_loop.cc:131 )	ChromeBrowserMainParts::MainMessageLoopRun(int*)
0x00005b9659e182f0	(chrome -browser_main_loop.cc:978 )	content::BrowserMainLoop::RunMainMessageLoopParts()
0x00005b9659e1b2a1	(chrome -browser_main_runner_impl.cc:169 )	content::BrowserMainRunnerImpl::Run()
0x00005b9659e112d7	(chrome -browser_main.cc:51 )	content::BrowserMain(content::MainFunctionParams const&, std::__1::unique_ptr<content::BrowserProcessSubThread, std::__1::default_delete<content::BrowserProcessSubThread> >)
0x00005b965b635d45	(chrome -content_main_runner_impl.cc:619 )	content::ContentMainRunnerImpl::Run()
0x00005b965b640754	(chrome -main.cc:459 )	service_manager::Main(service_manager::MainParams const&)
0x00005b965934a957	(chrome -content_main.cc:19 )	ChromeMain
0x000079f012507735	(libc-2.23.so -libc-start.c:289 )	__libc_start_main
0x00005b965933d888	(chrome + 0x00267888 )	_start
0x00007ffdd9b5b9c7	

which doesn't make much sense as there are no vectors being used in the ctor.

However - diving some call stack levels down, there is the window list (https://cs.chromium.org/chromium/src/chrome/browser/ui/ash/multi_user/user_switch_animator_chromeos.cc?type=cs&sq=package:chromium&g=0&l=229) and there must be the problem somewhere.

I expect therefore that crostini apps can be closed somehow without properly disengaging from the system.

Albert, can you please dispatch accordingly? 

hejq@ could we be failing to get the app_list_controller() at https://cs.chromium.org/chromium/src/chrome/browser/ui/ash/multi_user/user_switch_animator_chromeos.cc?type=cs&l=92 ?

Just back. Sorry for the delay.

I checked that this call was first introduced by https://codereview.chromium.org/1729373004, which showed app_list_controller could be null.

And the null check was omitted since https://chromium-review.googlesource.com/644724.

crrev.com/c/1079487 should fix this.

Thanks to xiyuan@ for commenting under the CL. I checked again and take back 5#.

Although a null check was omitted, but that makes sense since app_list_controller should always live with Shell. It can only be null there if Shell is being destructed or has been destructed..

Passing back to nverne@ for further checking. Please feel free to assign back if it becomes more likely an app list issue.

I can pretty easily repro on 68.0.3440.4 on eve.

I've just got it again on 68.0.3440.25: go/crash/dc41ffa1d75a600a

It happened as I signed-in with the second account.

This is still happening to me multiple times a day. It's easy to repro:

- Use multiple profiles.
- Start some crostini apps using launcher.
- Switch profile using keyboard shortcuts and it will very frequently crash.

It seems like if I avoid using the launcher, then the crash is not happening.

Can someone please check if it's happening on Canary for 69? I'm unable to reproduce at ToT, but I've only tried 
1. Log into primary
2. Start Crostini, install gEdit, start gEdit
3. Sign in another user
--- No crash
4. Use keyboard shortcuts to switch users
--- No crash, but if gEdit is in foreground, the shortcuts don't work.

I need to be using the launcher for the crash to happen. Try launching multiple apps and switch profiles in between launching the apps. 

Shortcuts are not expected to work unless you add them to the sommelier config. So that's WAI.

So one more thing: dstockwell@ showed me a crash with profile switching, but there was also an external display in use. 
Unplugging the external display made the crash go away. Plugging the external display back in afterwards, there was no longer a crash.

Have other users been using external displays?

I have not been using an external monitor.

It seems to be a bit harder to reproduce in latest dev-channel release. This is the last time I saw this crash: https://crash.corp.google.com/browse?stbtiq=c283e6c11ba6ecf0

That particular crash died due to nullptr returned from GetRootWindowSettings
https://crash.corp.google.com/browse?q=EXISTS+%28SELECT+1+FROM+UNNEST%28CrashedStackTrace.StackFrame%29+WHERE+FunctionName%3D%27MultiUserWindowManagerChromeOS%3A%3AActiveUserChanged%28user_manager%3A%3AUser+const*%29%27%29+AND+EXISTS+%28SELECT+1+FROM+UNNEST%28CrashedStackTrace.StackFrame%29+WHERE+FunctionName%3D%27ash%3A%3AScreenAsh%3A%3AGetDisplayNearestWindow%28aura%3A%3AWindow*%29+const%27%29&stbtiq=&reportid=&index=0

code:
https://codesearch.chromium.org/chromium/src/ash/display/screen_ash.cc?type=cs&q=GetRootWindowSettings&g=0&l=126

I'm not sure if it's an oversight to have no null check here, but it's possible Crostini is at fault. I suspect timzheng@ might have some insight. Perhaps this is a known problem and already fixed in ToT.

Tim, please assign back to me if this isn't appropriate.

It's not obvious to me that any Crostini shelf related code change could have fixed this. I don't know if it's fixed.
But I tried and couldn't reproduce it with TOT build. I tried to switch user multiple times very fast and it didn't crash. I plugged in an external monitor and start some Crostini app on both displays and switch users and no crash happened.
When I rapidly switch users the only issue I'm observing is that the Crostini shelf item showed the default penguin icon briefly during the switch before showing their right icon eventually. I don't think that's a big deal.
I'm assigning this back to nverne. I'm interested if there is an easy way to reproduce it.

I can still reproduce this in the latest dev channel update, 10866.1.0. Doesn't seem dependent on external monitor. The only app I'm running is VSCode.

All I do is sign into my secondary user, switch back, launch VSCode, then Ctrl+Alt+>.

What is the latest status of this issue? This is RBB, do you know the user impact? Need to prioritize a fix or risk impacting the release timelines.

This is not a regression for M69 and exists in M68, fix should be prioritized but not RBB M69.

We suspect this is fixed - or at least no longer reproducible.

This is still not fixed, happens to me often still. Chrome 70.0.3538.22

I do the same thing as dstockwell@google.com, I'm running VS Code and randomly (not every time) when switching profiles the whole thing crashes. 

I think newer instances of this are being tracker in  bug 889296 . Thanks!

Re-opening this, looks like the crashes are still present in the latest canary builds.

 Issue 889296  has been merged into this issue.

This happens to me every time I use my personal account for a few minutes.

I'm currently on 71.0.3558.0 (dev) but I have experienced this on 70.0.3538.16 (dev) and 70.0.3538.22 (beta).

I did install crostini a few weeks ago but I removed it because I thought it was causing these crashes.  Happens regardless of external monitor connected.

To repro:  
1. Log into my personal account (or switch to it with CTRL-ALT-.)
2. Use GMail, Gcalendar etc for a few minutes and system crashes.

Crash IDs from last 24 hours: 9faf2e9cacc09517, d4bf672176441567, 12ee0827ae348d18, d1eda5017ab9abed, 97a6243cbcdd6fb4.

I played around a bit and couldn't get this to crash yet (on a recent-ish ToT build), but I did notice that Crostini windows would be hidden on switching profiles (minimised/not in alt-tab) and you'd need to hit the shelf icon to get them to re-appear (subsequent switches don't affect it), which could be related. Can't really investigate right now but will look next week.

re comment 24: This bug is just for apparently Crostini-induced profile-switching crashes. AIUI the crash here happens immediately upon hitting ctrl-alt-dot.

I'm also still seeing crashes here frequently. Here's a recent one: https://crash.corp.google.com/browse?stbtiq=03bdb6aa4c3b82c5

Looks like a null pointer dereference close to the top of the call stack.

I continue to experience this problem as well.  Happened twice today with the latest being crash ID: 57660196c7419f40.  I'm on 69.0.3497.95.  This happens almost every time I'm using crostini and switch profiles. 

OK I still couldn't repro this as described but I got a (seemingly) reliable repro of the same stack trace by:
- Start multi-profile
- Open kwrite, type some letters
- Close kwrite (confirm dialog appears as a separate window)
- Immediately switch profiles

In BuildUserToWindowsListMap(), we get a window from window_to_entry which is non-null, but I think it might have been freed?

Will try debug more later but it may have to wait until next week.

Not sure if this is a similar bug, but I get random crashes when I'm using Crostini and only logged into one profile so not switching, but it seems to happen when going or coming back from sleep or something. Just happened, crash ID: 83157b845e3114c2

Could also have something to do with connecting or disconnecting to external monitor when coming in or out of sleep.

Maybe due to the transient window check in CrostiniAppWindowShelfController::OnWindowInitialized not working entirely, in some cases this gets called prior to AddTransientChild so we end up adding it to the MultiUserWindowManagerChromeOS when we shouldn't.

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

commit bf10ece3f79ead0ff1d488ae3b61fbc559e6f3c8
Author: Timothy Loh <timloh@chromium.org>
Date: Fri Oct 12 00:36:33 2018

Properly filter out transient Crostini windows from the shelf

Transient Crostini windows are supposed to be filtered from the shelf,
but we are checking for a transient parent on window Init, which is
before it actually gets set. This was causing a UAF on profile switching
as MultiUserWindowManagerChromeOS::SetWindowOwner() is not supposed to
be called with transient windows.

Bug:  845843 
Change-Id: Iec7b48cb03fff22775c31ce08c398ba750836463
Reviewed-on: https://chromium-review.googlesource.com/c/1266475
Commit-Queue: Timothy Loh <timloh@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#599038}
[modify] https://crrev.com/bf10ece3f79ead0ff1d488ae3b61fbc559e6f3c8/chrome/browser/ui/ash/launcher/crostini_app_window_shelf_controller.cc

I think this *just* missed M71 branch, requesting merge approval.

Your change meets the bar and is auto-approved for M71. Please go ahead and merge the CL to branch 3578 manually. Please contact milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit f10c33124be2997ab7497a5a2f1707f441eee3e3
Author: Timothy Loh <timloh@chromium.org>
Date: Mon Oct 15 23:53:25 2018

[M71 Merge] Properly filter out transient Crostini windows from the shelf

Transient Crostini windows are supposed to be filtered from the shelf,
but we are checking for a transient parent on window Init, which is
before it actually gets set. This was causing a UAF on profile switching
as MultiUserWindowManagerChromeOS::SetWindowOwner() is not supposed to
be called with transient windows.

Bug:  845843 
Change-Id: Iec7b48cb03fff22775c31ce08c398ba750836463
Reviewed-on: https://chromium-review.googlesource.com/c/1266475
Commit-Queue: Timothy Loh <timloh@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599038}(cherry picked from commit bf10ece3f79ead0ff1d488ae3b61fbc559e6f3c8)
Reviewed-on: https://chromium-review.googlesource.com/c/1282083
Reviewed-by: Timothy Loh <timloh@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#31}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/f10c33124be2997ab7497a5a2f1707f441eee3e3/chrome/browser/ui/ash/launcher/crostini_app_window_shelf_controller.cc

Fix should be in 71.0.3578.9 and onwards (hasn't been pushed out yet).

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

Commit: f10c33124be2997ab7497a5a2f1707f441eee3e3
Author: timloh@chromium.org
Commiter: timloh@chromium.org
Date: 2018-10-15 23:53:25 +0000 UTC

[M71 Merge] Properly filter out transient Crostini windows from the shelf

Transient Crostini windows are supposed to be filtered from the shelf,
but we are checking for a transient parent on window Init, which is
before it actually gets set. This was causing a UAF on profile switching
as MultiUserWindowManagerChromeOS::SetWindowOwner() is not supposed to
be called with transient windows.

Bug:  845843 
Change-Id: Iec7b48cb03fff22775c31ce08c398ba750836463
Reviewed-on: https://chromium-review.googlesource.com/c/1266475
Commit-Queue: Timothy Loh <timloh@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#599038}(cherry picked from commit bf10ece3f79ead0ff1d488ae3b61fbc559e6f3c8)
Reviewed-on: https://chromium-review.googlesource.com/c/1282083
Reviewed-by: Timothy Loh <timloh@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#31}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

Issue 907930 has been merged into this issue.