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

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

Automatically adding ccs based on suspected regression changelists:

Refactor checks to use a copy of the new logging backend. by jonasolsson@webrtc.org - https://webrtc.googlesource.com/src/+/f8e5c110ee806992f4092220339939fe5c2d3cc9

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

This looks like a false positive. Both the crash and original stacktrace correctly aborts after a DCHECK fails. It's reported as an abort on unknown address, probably because the check code has been changed slightly.

@aleloi: What's the sensible thing to do here? Do we need to register the new abort() address somewhere?

ClusterFuzz has detected this issue as fixed in range 568676:568680.

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

Fuzzer: libFuzzer_audio_processing_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: Abrt
Crash Address: 0x05390000267b
Crash State:
  rtc::webrtc_checks_impl::FatalLog
  Call<>
  webrtc::BlockBuffer::ExtractExtendedBlock
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=567943:567948
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=568676:568680

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

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

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