Details:

The build completes but my GN build of Chrome for ChromeOS/Ozone crashed on startup in a DCHECK. My GN build sets dcheck_always_on to true (or in GYP dcheck_always_on=1) With this set in GYP, the GN and GYP builds exhibit similar (unhappy) behaviour: crashing on start like so:

[30059:30059:0322/175701:FATAL:device_util_linux.cc(23)] Check failed: !base::MessageLoopForUI::IsCurrent().
#0 0x7f0f26b98394 base::debug::StackTrace::StackTrace()
#1 0x7f0f26bb67be logging::LogMessage::~LogMessage()
#2 0x7f0f213b0c1b ui::GetInputDeviceTypeFromPath()
#3 0x7f0f215dc0df ui::EventDeviceInfo::Initialize()
#4 0x7f0f2129930d ui::MaterialDesignController::DefaultMode()
#5 0x7f0f2129952b ui::MaterialDesignController::InitializeMode()
#6 0x7f0f2129967d ui::MaterialDesignController::GetMode()
#7 0x7f0f212996c9 ui::MaterialDesignController::IsModeMaterial()
#8 0x7f0f212a0db5 ui::ResourceBundle::LoadChromeResources()
#9 0x7f0f212a2c1f ui::ResourceBundle::InitSharedInstanceWithLocale()
#10 0x7f0f202696e6 ChromeBrowserMainParts::PreCreateThreadsImpl()
#11 0x7f0f2026a7f1 ChromeBrowserMainParts::PreCreateThreads()
#12 0x7f0f220d5739 content::BrowserMainLoop::PreCreateThreads()
#13 0x7f0f224ae90f content::StartupTaskRunner::RunAllTasksNow()
#14 0x7f0f220d817d content::BrowserMainLoop::CreateStartupTasks()
#15 0x7f0f220dc224 content::BrowserMainRunnerImpl::Initialize()
#16 0x7f0f220d46a2 content::BrowserMain()
#17 0x7f0f26af22e0 content::RunNamedProcessTypeMain()
#18 0x7f0f26af240c content::ContentMainRunnerImpl::Run()
#19 0x7f0f26af03f9 content::ContentMain()  
#20 0x7f0f20212282 ChromeMain
#21 0x7f0f1dd70fb6 __libc_start_main
#22 0x7f0f202120af <unknown>

I believe that this issue was introduced in https://codereview.chromium.org/1720273002.

Either the DCHECK is too conservative or MaterialDesignController is violating EventDeviceInfo's intended semantics. (http://crbug.com/597101 makes working on this bug inconvenient -- see that bug for a hacky workaround.)

vapier@, re comment #2, do you believe that "MaterialDesignController is violating EventDeviceInfo's intended semantics" ?

rjkroege@, a couple of questions for you:

1) Is this bug currently having a negative impact on any builders and/or the workflow of any developers? (Would you recommend reverting my change?)

2) I'm unclear what the relationship is between issue 597101 and this one. Would fixing issue 597101 fix this one?

Answers for tdanderson@: 

1. this bug does not impact builders or workflow. No revert is needed. That the DCHECK fires indicates a problem per my previous comment: either the DCHECK is wrong or the MaterialDesignController's implementation is incorrect and the fact that it works with DCHECKs disabled is fortuitous.

2. 597101 makes replicating this bug extra tedious but is entirely unrelated to this actual bug.

the dcheck came from https://codereview.chromium.org/688163004 ... it seems to have outlived its usefulness at this point, but i'm no expert

The DCHECK in question is making sure file IO is not happening on the UI thread. Is it really necessary for the MaterialDesignController to block the UI thread? (As is I think that the file enumerator would (D)CHECK later on anyways.)

Re #7, I believe so, since MaterialDesignController needs to know whether a touchscreen is present, and the only way to know that is to wait on a completed device scan.

dnicoara@ Would it make sense to replace that DCHECK with ThreadRestrictions::AssertIOAllowed() instead? That way, MaterialDesignController can use ScopedAllowIO* to explicitly express its intentions, and not hit the DCHECK.

[*] I don't think it should, and it needs to learn to deal with touchscreen availability asynchronously, because a touchscreen can be attached/initialized after chrome has started.

Re #9: I think that's fine. Having the explicit ScopedAllowIO will be a good sign of what's going on.

I also think there should be a comment in MaterialDesignController explaining why this is done and saying that the call in question is a one time call during startup. (At least that's how I read the code; if it isn't a one time call during startup then it is a different story and it needs to be fixed.)

tdanderson@ to expand on sadrul's comment. If I have a touchscreen-equipped ChromeBook and add an external non-touch monitor, do both get touch MD? And obviously: if I have a headless Chrome box, unplug the non-touch monitor and then plug in a touch screen, what should happen?

GYP ToT device build also crashes on this dcheck:

------- Full chrome log starts ------------
[23147:23147:0330/005209:WARNING:histogram_base.cc(131)] 2 histograms were created before reporting was enabled.
[1:1:0330/005210:WARNING:histogram_base.cc(131)] 2 histograms were created before reporting was enabled.
[1:1:0330/005210:VERBOSE1:zygote_main_linux.cc(598)] ZygoteMain: initializing 2 fork delegates
[1:1:0330/005211:VERBOSE1:zygote_main_linux.cc(314)] Unable to load plugin /opt/google/chrome/PepperFlash/libpepflashplayer.so /opt/google/chrome/PepperFlash/libpepflashplayer.so: cannot open shared object file
[23147:23147:0330/005211:VERBOSE1:drm_device_handle.cc(66)] Succeeded authenticating /dev/dri/card0
[23147:23147:0330/005211:FATAL:device_util_linux.cc(23)] Check failed: !base::MessageLoopForUI::IsCurrent(). 
#0 0x7f70b9729939 base::debug::StackTrace::StackTrace()
#1 0x7f70b977ed4b logging::LogMessage::~LogMessage()
#2 0x7f70b09354aa ui::GetInputDeviceTypeFromPath()
#3 0x7f70a09cad09 ui::EventDeviceInfo::Initialize()
#4 0x7f70a9a3a081 ui::MaterialDesignController::DefaultMode()
#5 0x7f70a9a3a38a ui::MaterialDesignController::InitializeMode()
#6 0x7f70a9a39df9 ui::MaterialDesignController::GetMode()
#7 0x7f70a9a39ec1 ui::MaterialDesignController::IsModeMaterial()
#8 0x7f70a9a50426 ui::ResourceBundle::LoadChromeResources()
#9 0x7f70a9a5bfd4 ui::ResourceBundle::LoadCommonResources()
#10 0x7f70a9a4d7a1 ui::ResourceBundle::InitSharedInstanceWithLocale()
#11 0x7f70befb884a ChromeBrowserMainParts::PreCreateThreadsImpl()
#12 0x7f70befb7e70 ChromeBrowserMainParts::PreCreateThreads()
#13 0x7f70b260456e content::BrowserMainLoop::PreCreateThreads()
#14 0x7f70b24cc773 _ZN4base8internal15RunnableAdapterIMNS_18CancelableCallbackIFvvEEEKFvvEE3RunIJEEEvPKS4_DpOT_
#15 0x7f70b260cb95 _ZN4base8internal12InvokeHelperILb0EiNS0_15RunnableAdapterIMN7content15BrowserMainLoopEFivEEEE8MakeItSoIJPS4_EEEiS7_DpOT_
#16 0x7f70b260c8ac _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIMN7content15BrowserMainLoopEFivEEEFiPS7_EJNS0_17UnretainedWrapperIS7_EEEEENS0_12InvokeHelperILb0EiSA_
#17 0x7f70b2470cd4 base::Callback<>::Run()
#18 0x7f70b3039523 content::StartupTaskRunner::RunAllTasksNow()
#19 0x7f70b2604b93 content::BrowserMainLoop::CreateStartupTasks()
#20 0x7f70b260d711 content::BrowserMainRunnerImpl::Initialize()
#21 0x7f70b260143b content::BrowserMain()
#22 0x7f70b240f531 content::RunNamedProcessTypeMain()
#23 0x7f70b2410c1f content::ContentMainRunnerImpl::Run()
#24 0x7f70b240e7fe content::ContentMain()
#25 0x7f70bb246f0a ChromeMain
#26 0x7f70bb246ea0 main
#27 0x7f70a6dd6fb6 __libc_start_main
#28 0x7f70bb246d49 <unknown>
-------------------------------------

This is peppy device and official debug build.

Thank you for the suggestions, I have created a CL here: https://codereview.chromium.org/1844033002

re #10, you are correct that it is at most a one-time call on startup/restart.

re #9/#11, if at least one touchscreen is detected at startup/restart we use material-hybrid, otherwise we use material. It is an intentional product decision (at least for the time being) to not switch back and forth between MD modes at runtime based on attaching or detaching external touchscreens.

 Issue 603178  has been merged into this issue.

An alternate approach is in progress here: https://codereview.chromium.org/1906563002/

However there is an issue with the tabstrip not being drawn properly. Steps to reproduce:

1. On a ChromeOS touchscreen device, switch the MD mode to non-material in about:flags.
2. Click restart at bottom of about:flags page.

What should happen:
All of the top chrome UI should be drawn in the material-hybrid variant since a touchscreen is present.

What happens instead:
Most of the UI is drawn as material-hybrid, except for the tabstrip (tabstrip1.png). Switching tabs results in tabstrip2.png.

Deleted: tabstrip1.png 101 KB

	tabstrip1.png 101 KB View Download

Deleted: tabstrip2.png 101 KB

	tabstrip2.png 101 KB View Download

I would imagine something isn't doing a new Layout() of the tabstrip area/browser top chrome on theme change in that case?

Note: the CL in #13 is landing in the meanwhile in order to unbreak the workflow of developers who have to keep commenting out the offending DCHECK.

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

commit 3368658a432ad62dc20b090fd97832707e77a929
Author: tdanderson <tdanderson@chromium.org>
Date: Fri May 06 22:40:08 2016

Permit MaterialDesignController to make IO call

As a one-time call on startup, permit
MaterialDesignController to check for
available touch devices on Chrome OS.

BUG= 596294 

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

[modify] https://crrev.com/3368658a432ad62dc20b090fd97832707e77a929/PRESUBMIT.py
[modify] https://crrev.com/3368658a432ad62dc20b090fd97832707e77a929/ui/base/material_design/material_design_controller.cc
[modify] https://crrev.com/3368658a432ad62dc20b090fd97832707e77a929/ui/events/devices/device_util_linux.cc

Moving this nonessential bug to the next milestone.

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

This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone.

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

This bug as described has been fixed. Filed issue 641957 to track follow-on work.