Looks legit.

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

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

Changed the status to 'Assigned' as per the Predator results.

gpu fuzzers: take configuration bits from input data by piman@chromium.org
Suspected changelist touched line(s) near the crashing line in gles2_cmd_decoder.cc (3572 lines away)
Suspected changelist touched file(s) in the directory gpu/command_buffer/service, which appears in the stack trace.
Suspected changelist touched file gles2_cmd_decoder.cc, which appears in the stack trace.
Suspected changelist touched file(s) associated with the component Internals>GPU>Internals, which we believe is related to this testcase based on information in OWNERS files.

Thanks.

Note, that CL unlocked coverage to this code path, the bug largely predates it. Will take a look.

ClearFramebufferForWorkaround asks for the GetBoundReadFramebufferSize, which is wrong, because it's writing to it. In this case, the draw framebuffer is 0, and the read framebuffer is !0 but not complete.

https://chromium-review.googlesource.com/c/chromium/src/+/753823 should fix this.

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

commit 6e3545f091f9ce772d8eb3e51a39409a5c1a253a
Author: Antoine Labour <piman@chromium.org>
Date: Mon Nov 06 21:49:33 2017

Fix draw size for clear workaround

The read framebuffer may not be the same as the draw framebuffer, so we
shouldn't use the read framebuffer's size to decide what area to clear.
At the same time, we don't need to restrict the size to anything, so we
can use the maximum viewport size.

Bug:  780666 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I38441728346e29922b01bdfba15bd5a45d5bf399
Reviewed-on: https://chromium-review.googlesource.com/753823
Commit-Queue: Antoine Labour <piman@chromium.org>
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#514248}
[modify] https://crrev.com/6e3545f091f9ce772d8eb3e51a39409a5c1a253a/gpu/command_buffer/service/gles2_cmd_clear_framebuffer.cc
[modify] https://crrev.com/6e3545f091f9ce772d8eb3e51a39409a5c1a253a/gpu/command_buffer/service/gles2_cmd_clear_framebuffer.h
[modify] https://crrev.com/6e3545f091f9ce772d8eb3e51a39409a5c1a253a/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/6e3545f091f9ce772d8eb3e51a39409a5c1a253a/gpu/command_buffer/tests/gl_clear_framebuffer_unittest.cc

ClusterFuzz has detected this issue as fixed in range 514238:514252.

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

Fuzzer: libFuzzer_gpu_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000018
Crash State:
  scoped_refptr<gpu::gles2::Framebuffer::Attachment>::operator->
  gpu::gles2::Framebuffer::GetFramebufferValidSize
  gpu::gles2::GLES2DecoderImpl::ClearFramebufferForWorkaround
  
Sanitizer: address (ASAN)

Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=514238:514252

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md 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 6684006363168768 is verified as fixed, so closing issue as verified.

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