I can't run with just --mus (stacktrace below)

[6920:6920:0111/145631.749026:ERROR:zygote_host_impl_linux.cc(111)] SUID sandbox binary is missing. Won't be able to adjust OOM scores.
[6920:6944:0111/145633.837150:ERROR:logging_chrome.cc(210)] Unable to create symlink /tmp/chrome/test-user/chrome_debug.log pointing at /tmp/chrome/test-user/chrome_debug_20180111-145633: File exists (17)
[6920:6920:0111/145633.858336:ERROR:display_manager.cc(1818)] Could not find display:36029742295586560
[6920:6920:0111/145635.013123:ERROR:wallpaper_controller.cc(1202)] User is ephemeral or guest! Fallback to default wallpaper.
[6920:6920:0111/145635.020660:FATAL:display_configurator.cc(546)] Check failed: current_display_state_ == MULTIPLE_DISPLAY_STATE_INVALID (2 vs. 0)

with --screen-config=400x400/i,400x400 it would complain about having 4 displays.

I noticed you commented out that DCHECK in your unified_crash_debugging_a.patch - is that necessary for normal --mus as well?

Commenting out DCHECK is being worked on. Bug is 800925.

Hmm, that screen config shouldn't yield 4 displays... can you post the warning?
Yup, as Scott said, I commented out the DCHECK for  Issue 800925 .

@msw: sry, I meant with --screen-config=400x400/i,400x400, but without commenting out that DCHECK, it would complain "Check failed: current_display_state_ == MULTIPLE_DISPLAY_STATE_INVALID (4 vs. 0)"

update: So it doesn't seem to only occur occasionally for me - I can always repro on my workstation. 

Received signal 11 SEGV_MAPERR 000000000010
    #0 0x5578a0a071e1 in __interceptor_backtrace /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:3867:13
    #1 0x7f6c2602e40c in base::debug::StackTrace::StackTrace(unsigned long) /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../base/debug/stack_trace_posix.cc:808:41
    #2 0x7f6c2602d20d in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../base/debug/stack_trace_posix.cc:334:3
    #3 0x7f6bf2e11330 in _L_unlock_13 ??:?
    #4 0x7f6bf2e11330 in ?? ??:0
    #5 0x7f6c1f70201c in ui::ws::WindowManagerDisplayRoot::GetClientVisibleRoot() const /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../services/ui/ws/window_manager_display_root.cc:46:7
    #6 0x7f6c1f6a64f2 in ui::ws::EventTargeter::FindTargetForLocationNow(viz::EventSource, ui::ws::EventLocation const&, base::OnceCallback<void (ui::ws::EventLocation const&, ui::ws::DeepestWindow const&)>) /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../services/ui/ws/event_targeter.cc:47:50
    #7 0x7f6c1f6a6282 in ui::ws::EventTargeter::FindTargetForLocation(viz::EventSource, ui::ws::EventLocation const&, base::OnceCallback<void (ui::ws::EventLocation const&, ui::ws::DeepestWindow const&)>) /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../services/ui/ws/event_targeter.cc:39:5
    #8 0x7f6c1f699bf4 in ui::ws::EventDispatcher::UpdateCursorProviderByLastKnownLocation() /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../services/ui/ws/event_dispatcher.cc:227:22
    #9 0x7f6c1f6d496e in ui::ws::ServerWindow::SetBounds(gfx::Rect const&, base::Optional<viz::LocalSurfaceId> const&) /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../services/ui/ws/server_window.cc:239:14
    #10 0x7f6c1f74b80d in ui::ws::WindowTree::SetWindowBounds(unsigned int, unsigned int, gfx::Rect const&, base::Optional<viz::LocalSurfaceId> const&) /usr/local/google/home/riajiang/chromium/src/out/oxygencros/../../services/ui/ws/window_tree.cc:1783:13

I tracked it down to display->GetWindowManagerDisplayRootForUser(user_id()) having null value in WindowManagerState::GetRootWindowForDisplay. Simply return nullptr if display->GetWindowManagerDisplayRootForUser(user_id()) is null didn't solve the problem (it doesn't crash but tab strip just gets copied many times...).

Since you are seeing a different behavior (only crashes occasionally), I was wondering if you can check whether display->GetWindowManagerDisplayRootForUser(user_id()) is null when it crashes for you? Am I still testing this wrong?

Hey, I'm sorry for the inconvenience, I found a better fix that doesn't hit this crash:
  https://chromium-review.googlesource.com/c/chromium/src/+/872460

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

commit 8443bcccab0cc8a1e88cda27da0ca41d6064cdcb
Author: Mike Wasserman <msw@chromium.org>
Date: Thu Jan 18 19:29:07 2018

mus: Fix missing internal display crash for unified mode

Bug:  801257 ,  764472 
Change-Id: I74ec33e1e1ee35312a43b3bed4e2c1a3042c57b9
Reviewed-on: https://chromium-review.googlesource.com/872460
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Michael Wasserman <msw@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530228}
[modify] https://crrev.com/8443bcccab0cc8a1e88cda27da0ca41d6064cdcb/services/ui/ws/display_manager.cc