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.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/252af33418128e61b71b9afe20eba98ad5ed6a5c (cc/ipc: Don't fail filter serialization on insufficent buffer.).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

This is crashing because our serialization code never expects there to be null images, which is a valid assumptions because we don't allow them in recordings on the renderer.

But when deserializing the op, its valid to have null images, this happens when the decode failed. Since the fuzzer then tries to re-serialize the op, it tries to de-reference a null image.

I think this should be a clusterfuzz-ignore. I don't see an easy way of avoiding re-serializing such ops in the fuzzer, since the image could be deeply embedded in it. enne@, any alternate ideas?

Yeah, I think our options here are to ignore it during serialization or to clusterfuzz ignore it.

I think it'd be consistent to do what PaintOpWriter::Write(PaintImage&) does in this case and write that there's no image.  Why do you say this is something that wouldn't happen in practice?

PaintOpWriter::Write(PaintImage&) is doing a null check because its being used to serialize images in a PaintShader, which can be null if the shader is not Type::kImage.

But for DrawImage/DrawImageRectOps where this is being hit, it feels like we shouldn't have callers create ops with null images in recordings on the renderer. Or maybe that's okay?

What do we do when the decoding fails? Is it not a null image then?

The recorded PaintImage is always valid, the decoded image which we serialize is null. Its the problem of re-serializing an op after it has been deserialized. The ops the renderer will serialize will never have null images. But the ones deserialized in the GPU can, if we couldn't decode that image in the renderer. If you then to re-serialize them now, you'll encounter null images.

I think given that a failed decode turns into a null SkImage that it'd be reasonable to just support a null SkImage during (re)serialization.  Does that seem ok to you?

Sure. #10 sounds fine.

 Issue 841361  has been merged into this issue.

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

commit e8c9fe649a94afede6aa3012cf42d370a5e69cac
Author: Khushal <khushalsagar@chromium.org>
Date: Mon Jun 11 23:25:42 2018

cc: Handle null images during PaintOp serialization.

R=enne@chromium.org

Bug:  839565 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id20994979365627ae4a2e01821046b98c1b838e7
Reviewed-on: https://chromium-review.googlesource.com/1093581
Commit-Queue: Khushal <khushalsagar@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#566198}
[modify] https://crrev.com/e8c9fe649a94afede6aa3012cf42d370a5e69cac/cc/paint/paint_op_buffer.cc
[modify] https://crrev.com/e8c9fe649a94afede6aa3012cf42d370a5e69cac/cc/paint/paint_op_buffer_unittest.cc
[modify] https://crrev.com/e8c9fe649a94afede6aa3012cf42d370a5e69cac/cc/paint/paint_op_writer.cc

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

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

ClusterFuzz testcase 5498225394712576 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

ClusterFuzz has detected this issue as fixed in range 566191:566201.

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

Fuzzer: libFuzzer_paint_op_buffer_eq_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x00000000000c
Crash State:
  SkImage::width
  cc::CreateDrawImage
  cc::DrawImageOp::Serialize
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=536643:536651
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=566191:566201

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

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 has detected this issue as fixed in range 566191:566201.

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

Fuzzer: libFuzzer_paint_op_buffer_eq_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x00000000000c
Crash State:
  SkImage::width
  cc::CreateDrawImage
  cc::DrawImageOp::Serialize
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=536643:536651
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=566191:566201

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

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 has detected this issue as fixed in range 566191:566201.

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

Fuzzer: libFuzzer_paint_op_buffer_eq_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x00000000000c
Crash State:
  SkImage::width
  cc::CreateDrawImage
  cc::DrawImageOp::Serialize
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=536643:536651
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=566191:566201

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

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.