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

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

Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

Looks like this is just a correctness assert, and nothing crashes or goes awry if an incorrect blend state is used here.

bsalomon: I was curious, I had been validating that blend modes were no bigger than kLastMode, but it looks like drawRect requires that blend modes be < kLastCoeffMode.  I assume this is not true for all SkPaint blend modes?

 Issue 840093  has been merged into this issue.

It shouldn't require that. If so it's a bug.

Here is my guess:

The underlying type for SkBlendMode is signed. The mode value is negative. Earlier in non-assertion code we check whether mode < kScreen (AKA kLastCoeffMode) in SkBlendMode_AsCoeff. This passes and we proceed as though this were a coeff mode. However, the assertion casts mode to unsigned before comparing to kLastCoeffMode which then fails. 

You're quite right.  It's a -1 blend mode.

ClusterFuzz has detected this issue as fixed in range 578890:578891.

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

Fuzzer: afl_paint_op_buffer_fuzzer
Job Type: afl_chrome_asan
Platform Id: linux

Crash Type: Abrt
Crash Address: 0x05390000052b
Crash State:
  GrPorterDuffXPFactory::Get
  skpaint_to_grpaint_impl
  SkPaintToGrPaint
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=afl_chrome_asan&range=555636:555647
Fixed: https://clusterfuzz.com/revisions?job=afl_chrome_asan&range=578890:578891

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

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.