I was able to reproduce this earlier. At ToT (r387909) there is something that causes chrome to crash before it reaches this point.

A similar crash when opacity has been set on mus::ServerWindow

[13348:13348:0421/123119:174864566770:FATAL:compositor.cc(436)] Check failed: false. 
#0 0x7f32837dae8e base::debug::StackTrace::StackTrace()
#1 0x7f3283830abc logging::LogMessage::~LogMessage()
#2 0x7f32789235ab ui::Compositor::DidFailToInitializeOutputSurface()
#3 0x7f3278e4e760 cc::LayerTreeHost::DidFailToInitializeOutputSurface()
#4 0x7f3278f10985 cc::SingleThreadProxy::SetOutputSurface()
#5 0x7f3278e4df8a cc::LayerTreeHost::SetOutputSurface()
#6 0x7f32789225ed ui::Compositor::SetOutputSurface()
#7 0x7f3274b08f8e views::SurfaceContextFactory::CreateOutputSurface()
#8 0x7f3278923519 ui::Compositor::RequestNewOutputSurface()
#9 0x7f3278e4e3fd cc::LayerTreeHost::RequestNewOutputSurface()
#10 0x7f3278f1047d cc::SingleThreadProxy::RequestNewOutputSurface()
#11 0x7f3278c30ae9 _ZN4base8internal15RunnableAdapterIMN2cc28ScrollbarAnimationControllerEFvvEE3RunIJEEEvPS3_DpOT_
#12 0x7f3278c30a50 _ZN4base8internal12InvokeHelperILb1EvNS0_15RunnableAdapterIMN2cc28ScrollbarAnimationControllerEFvvEEEE8MakeItSoINS_7WeakPtrIS4_EEJEEEvS7_T_DpOT0_
#13 0x7f3278f1767d _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIMN2cc17SingleThreadProxyEFvvEEEFvPS7_EJNS_7WeakPtrIS7_EEEEENS0_12InvokeHelperILb1EvSA_EEFvvEE3RunEPNS0_13BindStateBaseE
#14 0x7f3278c30b3e base::Callback<>::Run()
#15 0x7f3278c307d9 base::CancelableCallback<>::Forward()
#16 0x7f3278c30ae9 _ZN4base8internal15RunnableAdapterIMN2cc28ScrollbarAnimationControllerEFvvEE3RunIJEEEvPS3_DpOT_
#17 0x7f3278c30a50 _ZN4base8internal12InvokeHelperILb1EvNS0_15RunnableAdapterIMN2cc28ScrollbarAnimationControllerEFvvEEEE8MakeItSoINS_7WeakPtrIS4_EEJEEEvS7_T_DpOT0_
#18 0x7f3278c309fd _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIMNS_18CancelableCallbackIFvvEEEKFvvEEEFvPKS8_EJNS_7WeakPtrIS8_EEEEENS0_12InvokeHelperILb1EvSB_EES7_E3RunEPNS0_13BindStateBaseE
#19 0x7f32837bedfe base::Callback<>::Run()
#20 0x7f32837e063e base::debug::TaskAnnotator::RunTask()
#21 0x7f328384c251 base::MessageLoop::RunTask()
#22 0x7f328384c4d8 base::MessageLoop::DeferOrRunPendingTask()
#23 0x7f328384c6a2 base::MessageLoop::DoWork()
#24 0x7f328385e14c base::MessagePumpLibevent::Run()
#25 0x7f328384bcca base::MessageLoop::RunHandler()
#26 0x7f32838e2884 base::RunLoop::Run()
#27 0x7f328384afa1 base::MessageLoop::Run()
#28 0x7f32844d5f60 MashRunner::StartChildApp()
#29 0x7f32844e3fce _ZN4base8internal15RunnableAdapterIM10MashRunnerFvN4mojo16InterfaceRequestIN5shell5mojom11ShellClientEEEEE3RunIJS8_EEEvPS2_DpOT_
#30 0x7f32844e3f11 _ZN4base8internal12InvokeHelperILb0EvNS0_15RunnableAdapterIM10MashRunnerFvN4mojo16InterfaceRequestIN5shell5mojom11ShellClientEEEEEEE8MakeItSoIJPS3_S9_EEEvSC_DpOT_
#31 0x7f32844e3ebd _ZN4base8internal7InvokerINS_13IndexSequenceIJLm0EEEENS0_9BindStateINS0_15RunnableAdapterIM10MashRunnerFvN4mojo16InterfaceRequestIN5shell5mojom11ShellClientEEEEEEFvPS6_SC_EJNS0_17UnretainedWrapperIS6_EEEEENS0_12InvokeHelperILb0EvSF_EEFvSC_EE3RunEPNS0_13BindStateBaseEOSC_
#32 0x7f328452a6b3 base::Callback<>::Run()
#33 0x7f3288a9c408 shell::ChildProcessMain()
#34 0x7f32844d5b36 MashRunner::RunChild()
#35 0x7f32844d59ff MashRunner::Run()
#36 0x7f32844d6054 MashMain()
#37 0x7f32844d1c26 ChromeMain
#38 0x7f32844d1ba2 main
#39 0x7f32718f3ec5 __libc_start_main
#40 0x7f32844d1a84 <unknown>

So the crash happens in cc::GLRenderer::DrawRenderPassQuad(). One of the method parameters is "const RenderPassDrawQuad* quad". Contained in quad->shared_quad_state->blend_mode is an SkXfermode::Mode which is used to determine the blending mode.

The problem is that quad->shared_quad_state->blend_mode = SkXfermode::kSrc_Mode. This doesn't appear to be a valid mode and it hits a NOTREACHED() in BlendModeFromSkXfermode() or triggers DCHECK() in GLRenderer::ApplyBlendModeUsingBlendFunc().

Turning off DCHECKS or just commenting out the offending ones keeps it from crashing as a super hacky workaround.

I can't be sure, but I feel like the crashes happens most frequently when I hover over some content on the chrome window that causes the status-window (https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/views/status_bubble_views.cc&sq=package:chromium&type=cs&l=582&rcl=1461237811) to show up. Perhaps the views::Widget is doing something funky? (e.g. it looks like it attempts to set the opacity to 0?)

We've had opacity 0 bugs before from animations. Compositor doesn't like that. We had to set opacity to near 0, then turn off visibility

Interesting. jonross@: Are there links to relevant bugs/CLs?

Yep, it's definitely caused by StatusBubbleViews::StatusView. When StatusBubbleViews::StatusView::StartHiding() or StatusBubbleViews::StatusView::StartShowing() gets called it crashes. No crash without those calls.

I suspect something might be broken in the CompositorFrame type converter: https://code.google.com/p/chromium/codesearch#chromium/src/mojo/converters/surfaces/surfaces_type_converters.cc&sq=package:chromium&type=cs&l=606&rcl=1461237811

#9 I can't seem to find any particular CL/Bug. I recall it came up with animating the shelf/status area a few years back.

So #10 blaming that area of the code doesn't surprise me

It looks like this is triggered by transparent quads. In SurfaceAggregator::HandleSurfaceQuad() if there is a transparent quad it creates a new RenderPassDrawQuad that inherits the blend_mode which happens to be SkXfermode::kSrc_Mode. That RenderPassDrawQuad is then handled by GLRenderer and it tries to draw it then crashes.

The root cause of this appears to be because GLRenderer::use_blend_equation_advanced_=false with use_ozone=true builds. This value is retrieved via output_surface_->context_provider()->ContextCapabilities() in GLRenderer::GLRenderer().

https://code.google.com/p/chromium/codesearch#chromium/src/cc/output/gl_renderer.cc&l=341

So it's coming from the ContextProvider for what I think is the top level OutputSurface? If you build the Desktop X11 mash build then GLRenderer::use_blend_equation_advanced_=true instead and there is no crash. With the Ozone mash build then it's false and it crashes because it can't handle the blend_mode for the RenderPassDrawQuad.

More interesting is that for Ozone Chrome OS chrome build (aka not mash) then GLRenderer::use_blend_equation_advanced_=false. So it appears this is intended. This build doesn't crash because no transparent quads make it GLRenderer. They must be handled at some earlier stage of drawing?

We could possibly never be generating fully transparent quads on CrOS.

Maybe change the opacity of a root window? See if it can repro

It's not just fully transparent quads that will crash it. It's any opacity other than 1.0f.

The interesting bit here is that the shelf window does have large transparent regions, and that does work correctly without triggering any crashes. I suppose this is because the Widget has a transparent background, but itself is not transparent. But presumably an empty and non-transparent Widget with a transparent background would/should generate the same CompositorFrame data as a transparent Widget? Can we verify if that is indeed the case? (e.g. hide all the Views in the shelf, so that the shelf becomes completely empty)

+some cc/gpu folks who might have thoughts.

Just for some more context the crash is happening in the mus process. The check for if the SurfaceDrawQuad is transparent happens here:

https://code.google.com/p/chromium/codesearch#chromium/src/cc/surfaces/surface_aggregator.cc&sq=package:chromium&type=cs&l=204

If the SurfaceDrawQuad is transparent then a RenderPassDrawQuad gets generated here:

https://code.google.com/p/chromium/codesearch#chromium/src/cc/surfaces/surface_aggregator.cc&sq=package:chromium&type=cs&l=275

That is the object that GLRenderer crashes on.

Random (probably incorrect0 thought: Could there be a rounding bug here? What is the exact value of surface_quad->shared_quad_state->opacity?

If the crashing DHECKS are commented out then opacity seems to go 0.0 -> 1.0 in a few steps over the course of multiple frames (as the StatusView fades in).

Where is kSrc_Mode coming from as a blend mode? Layer::SetBlendMode doesn't support that at the moment.

I suggested that sky add dchecks in RenderSurfaceImpl::AppendQuads to try figure out where this blend mode is coming from.

kSrc_Mode comes from the SurfaceDrawQuad SharedQuadState. That gets copied into the RenderPassDrawQuad when it's created.

https://code.google.com/p/chromium/codesearch#chromium/src/cc/surfaces/surface_aggregator.cc&q=SurfaceAggregator::HandleSurfaceQuad&sq=package:chromium&type=cs&l=271

Sure, but how does kSrc_Mode get into the SharedQuadState? Which layer is producing the SharedQuadState originally that has such a blend mode?

Right. Looks like we're doing that in DrawWindowTree() here:

https://code.google.com/p/chromium/codesearch#chromium/src/components/mus/ws/platform_display.cc&sq=package:chromium&type=cs&l=121

Ah, ok.  Is that intended to be kSrc_Mode and not kSrcOver_Mode?

If you really want to use kSrc_Mode, then we should fix GLRenderer to support that.

I have no idea honestly but maybe sky@ does? It could just be we want kSrcOver_Mode instead. Thanks for the help in tracking down what the problem is.

I don't believe SrcOver vs Src would make a difference for the display CompositorFrame which is what DrawWindowTree is generating. I would use SrcOver.

This all sounds good. We need to fix the IPC validation, because invalid client data must not crash/assert the service side - we should refuse the message instead.

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

commit b97005f01da370fa7b59b65ce7d1eb2eca1fa205
Author: kylechar <kylechar@chromium.org>
Date: Mon Apr 25 18:22:41 2016

Fix mash chrome crashing when hovering over link.

When built for ozone, mash crashes whenever the user hovers over a link
in chrome and the URL is shown in the bottom left corner. This happens
because PlatformDisplay uses an invalid blending mode for the partially
transparent quad that contains the URL. Change blending mode to not
crash.

BUG= 604109 

Review URL: https://codereview.chromium.org/1919673005

Cr-Commit-Position: refs/heads/master@{#389512}

[modify] https://crrev.com/b97005f01da370fa7b59b65ce7d1eb2eca1fa205/components/mus/ws/platform_display.cc

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

commit b97005f01da370fa7b59b65ce7d1eb2eca1fa205
Author: kylechar <kylechar@chromium.org>
Date: Mon Apr 25 18:22:41 2016

Fix mash chrome crashing when hovering over link.

When built for ozone, mash crashes whenever the user hovers over a link
in chrome and the URL is shown in the bottom left corner. This happens
because PlatformDisplay uses an invalid blending mode for the partially
transparent quad that contains the URL. Change blending mode to not
crash.

BUG= 604109 

Review URL: https://codereview.chromium.org/1919673005

Cr-Commit-Position: refs/heads/master@{#389512}

[modify] https://crrev.com/b97005f01da370fa7b59b65ce7d1eb2eca1fa205/components/mus/ws/platform_display.cc

Bulk verified

bulk verified