Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Predator could not provide any possible suspects.

From the above CL observing some changes related to 'viz' , hence suspecting the same

Suspect CL: https://chromium.googlesource.com/chromium/src/+/af93a1eedbc47abde6900376bdfa1d3ed1dd8f3f

kylechar@ -- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Nope, af93a1eedbc47abde6900376bdfa1d3ed1dd8f3f isn't related. There is nothing in regression range that looks like it could cause this failure. It also looks like the failure has only ever happened once? I tried to rerun the failure in ClusterFuzz, let's see if it reproduced.

Seems like it still reproduces at a later revision. I don't see anything in the regression range that could cause it though.

+trchen who added the DCHECK. Any ideas?

The DCHECK verifies the GL extension for advanced blending mode is available before invoking it. If a quad needs special blending mode we first check whether it is supported by GL extension, if not, a fragment shader will be used instead. Hitting this DCHECK means we have a quad with a blend mode that is not supported natively, but somehow we didn't apply it by a fragment shader either.

It maybe related to line #1087: https://chromium.googlesource.com/chromium/src/+blame/69140f3b316fb35fd7be22884e0602962d21aacd/components/viz/service/display/gl_renderer.cc#1087
Where use_shaders_for_blending was reset to false, but we never checked the expected blend mode or whether it is supported natively.

+erickn for components/viz/service/display/gl_renderer.cc:1087

My changes to GLRenderer were almost 2 years ago, and dealt with mac-specific compositing. The CL pointed to in c#6 is a refactor with no behavior change.

Given that this is a [likely] recent Linux crash, seems like the viz team should own this issue. 

GLRenderer::UpdateRPDQShadersForBlending() does seem to be part of the problem. params->background_rect is empty, this is because GLRenderer::GetBackdropBoundingBoxForRenderPassQuad() returns an empty rect when it intersects [1]. |backdrop_rect| is 7,-14 919x20 and moved RenderPass::output_rect is 0,17 933x239. params->background_texture is also zero, so params->use_shaders_for_blending is set to false at [2].

[1] https://cs.chromium.org/chromium/src/components/viz/service/display/gl_renderer.cc?l=750&rcl=6152ceb09e2b37d0b51bd8c1366dd027eb8acae7
[2] https://cs.chromium.org/chromium/src/components/viz/service/display/gl_renderer.cc?l=1087&rcl=f8617dddbbdf3735052ea5787af1589221279306

It problem seems to be that RenderPassDrawQuad that has the filter applied to it isn't visible with window size of 958,414. If you load the test case with and DCHECKs enabled it crashes. With DCHECKs disabled you get default.png. If you make the window slightly larger you can see the element that has the filter in bigger_window.png.

I'm not familiar with this code to say what the correct behaviour is here. Should the RenderPassDrawQuad have been remove from the display frame so this doesn't happen? +weiliangc/enne for help triage.

Deleted: default.png 38.2 KB

	default.png 38.2 KB View Download

Deleted: bigger_window.png 39.0 KB

	bigger_window.png 39.0 KB View Download

Deleted: fuzz-32.html 521 bytes

fuzz-32.html 521 bytes View Download

Yeah, it seems like if you're getting into [2] above, then we're in a state where we're not going to draw that background filter.  We probably should explicitly handle this case and not try to set a blend mode for it (and possibly skip the quad entirely).

ClusterFuzz testcase 5250338471542784 appears to be flaky, updating reproducibility label.

ClusterFuzz testcase 5250338471542784 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

 Issue 869596  has been merged into this issue.