Predator and CL could not provide any possible suspects.

Using Code Search for the file, "layer_tree_host.cc" suspecting the below Cl might have caused this issue

Suspect CL: https://chromium.googlesource.com/chromium/src/+/9fe572d2abb4f69e3ab2fa7d6095eb77b81843a3

fsamuel@ -- 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!

jonross@ could you please look at this?

So this is a similar issue to what is seen in  issue 899482 

The CHECK listed in #1 is no longer occurring. Instead we see a crash in  Display::DrawAndSwap, as renderer_->DrawFrame is called with a Size that is larger than max int. So gfx::Size is throwing an error when checking the size.

This is due to a request from the test runner:  
 TestRunnerBindings::SetBackingScaleFactor(1.84467e+19)
Currently we cap this to a scale factor of 100, however that still ends up trying to generate a rect of size 80000x60000 which is too large.

I can look into further capped this value at the test interface. However what I'm not sure of is why this is only being invoked on Mac. The same clusterfuzz test case does not make this call on Linux. 

+pfeldman@ as a content/shell/test_runner Owner whom works on Dev Tools. Would you have any insight into why I wouldn't be seeing this test api called on Mac?

So we have different potential error states, dependent on what value is used to cap the scale factor.

100 - gfx::Size checks upon area
50  - GLES2DecoderImpl::TexStorageImpl fails with "dimensions out of range"
20  - GL ERROR :GL_OUT_OF_MEMORY : BackFramebuffer::Destroy: <- error from previous GL command
19  - no error

However this is solely tied to the size requested by the test. In this case of this fuzzer it's 800*600. So we can "fix" this failure. However that doesn't generalize across future fuzzing cases.

I'm not sure where would be the most appropriate place to lock down scale factor. Especially as these are values we wouldn't be seeing in production.

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

commit ae938e031d1206fd601ff1388cc0dc4f92399c65
Author: Jonathan Ross <jonross@chromium.org>
Date: Wed Nov 28 22:14:47 2018

Fix Mac Giant Surface Fuzzer Crash

TestRunnerBindings::SetBackingScaleFactor allows our
test suites to simulate device scale factor changes.
Currently it caps the scale factor at 100x, based on
previous crashes seen in  https://crbug.com/899482 

However we hit similar crashes for lower scale factors
when working with larger initial sizes. In this fuzz
case 800x600 size, but a scale request of 1x10^17.

There are a few different potential crashes as a result:
  - 100x = gfx::Size::GetCheckedArea overflows int (80000x60000)
  -  50x = GLES2DecoderImpl::TexStorageImpl fails with "dimensions out of range"
  -  20x = GL ERROR :GL_OUT_OF_MEMORY
  -  19x = no error

I've elected to go with 15x. However there is nothing
explicit in this API to prevent similar crashes when
using larger sized surfaces. No displays currently use
scale factors this large, so there is no issue to be
concerned of in production.

Bug:  900271 
Change-Id: Icd0f75813b07f98bc51c56535000f2513cbceaa1
Reviewed-on: https://chromium-review.googlesource.com/c/1352612
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611892}
[modify] https://crrev.com/ae938e031d1206fd601ff1388cc0dc4f92399c65/content/shell/test_runner/test_runner.cc

ClusterFuzz has detected this issue as fixed in range 611876:611909.

Detailed report: https://clusterfuzz.com/testcase?key=5683157364637696

Fuzzer: inferno_twister
Job Type: mac_asan_content_shell
Platform Id: mac

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !has_pushed_local_surface_id_from_parent_ || new_local_surface_id_request_ || !l
  cc::LayerTreeHost::SetViewportSizeAndScale
  content::RenderWidget::UpdateSurfaceAndScreenInfo
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_content_shell&range=602103:602140
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_content_shell&range=611876:611909

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5683157364637696

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 5683157364637696 is verified as fixed, so closing issue as verified.

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