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/+/d5f07c6849faa9a88e6358eb001de5a75443d791 (MSE: When buffering ByPts, handle keyframe with PTS < previous keyframe).

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.

I have a local repro...

CL in review at https://chromium-review.googlesource.com/c/chromium/src/+/1352043

ClusterFuzz testcase 5005367412785152 appears to be flaky, updating reproducibility label.

Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.

ClusterFuzz has detected this issue as fixed in range 621021:621022.

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

Fuzzer: libFuzzer_mediasource_MP4_AACLC_pipeline_integration_fuzzer
Fuzz target binary: mediasource_MP4_AACLC_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  new_duration != kInfiniteDuration in chunk_demuxer.cc
  media::ChunkDemuxer::IncreaseDurationIfNecessary
  void base::internal::FunctorTraits<void
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=516777:516819
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=621021:621022

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

See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

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

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

Hmm, this is not fixed, it just took time to hit the timeout and there's now a default timeout in the runloop. See d9e4cb77324a3d4e0dfd6b599ce34e1224fdedb6 -- +wez, mmoroz