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 assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/49613c27bcd84170395588a6d93fc009eb988658 ([Zucchini]: Write fuzz generated patches).

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.

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

commit 54bf0d1da91c3db9a3682b840f7c76faa93c0072
Author: Calder Kitagawa <ckitagawa@chromium.org>
Date: Fri Jun 01 16:12:01 2018

[Zucchini]: Disable CHECK for ZTF Gen Fuzzer patch size

The fuzzer is really smart; it discovered the worst case patch scenario
of alternating 16 byte regions of ZTF and Raw regions. This resulted in
a 310 B testcase (17 B source file) generating a 2.5 ~kB patch
(uncompressed) (470 B compressed). This is the absolute worst case
behavior which requires an intentionally badly designed archive/input.
In reality this would never occur with valid binaries. It is good to
know that this case exists but there isn't much that can be done to
prevent it in Zucchini so we can just disable this check.

Two solutions to this could be:
1. Make Zucchini smart enough to try multiple patches, compare the
   compressed size and choose the best option.
2. Ignore it and in infra compare:
   - Compressed ensemble patch
   - Compressed raw patch
   - Compressed image
   Then just ship the smallest.

Option 1 adds a lot of complexity. Ideally, Zucchini should remain
naive with regards to generating compressed patches so that the infra
can choose the preferred compression and keep Zucchini fast.

The case for making the infra smarter is compelling and probably the
solution to pursue. However, because we have control over the input
binaries and this case will realistically not occur it isn't a
priority.

Bug:  848503 
Change-Id: Ic505db49fd89f12dbd1eb5b100a59832f6054b2e
Reviewed-on: https://chromium-review.googlesource.com/1082008
Reviewed-by: Samuel Huang <huangs@chromium.org>
Commit-Queue: Calder Kitagawa <ckitagawa@chromium.org>
Cr-Commit-Position: refs/heads/master@{#563662}
[modify] https://crrev.com/54bf0d1da91c3db9a3682b840f7c76faa93c0072/components/zucchini/fuzzers/ztf_gen_fuzzer.cc

ClusterFuzz has detected this issue as fixed in range 563655:563681.

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

Fuzzer: libFuzzer_zucchini_ztf_gen_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  patch_size <= kMaxImageSize * 2 in ztf_gen_fuzzer.cc
  TestOneProtoInput
  ztf_gen_fuzzer.cc
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=563261:563272
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=563655:563681

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

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 4932558350188544 is verified as fixed, so closing issue as verified.

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