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/+/c4c936cf14b8c7f125a6087241b7b7983644ee49 (MSE: Signal SBS of new CFG more granularly when buffering ByPts).

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 on ToT. Investigating...

Repro case:
Append an audio buffer A1 that starts N microseconds before the appendwindow start (e.g. default 0) and that is N+M=D microseconds duration. The coded frame processing algorithm front-clips the buffer by N microseconds, yielding a frame to be buffered at time [0,M) with duration M, and discard padding {N,0}.

Append another audio buffer A2 that starts X microseconds, where 0<X<M, and (M-X) is large; with similar duration to D. Splice overlap trims A1 further by (M-X): resulting with A1 having discard padding {N, M-X}. A2 is buffered fully, end-adjacent to A1.

Audio-discard helper DCHECK-fails on handling the decoded output of A1 when the number of decoded frames is completely consumed by the front-discard without yet even considering the end discard:

OnBufferReady<audio>: 0, timestamp=0 duration=419430690000000 size=1031 side_data_size=0 is_key_frame=1 encrypted=0 discard_padding (ms)=(8421202500, 645889    931500)
...
Front discard of 1024 out of 1024 frames starting at 0
Check failed: current_discard_padding.second.is_zero().
...

For now, this looks like its P2, but should be fixed. Bad media must still not violate our code's assumptions.

ClusterFuzz testcase 5463123977568256 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.

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=5463123977568256

Fuzzer: libFuzzer_mediasource_MP4_AACSBR_pipeline_integration_fuzzer
Fuzz target binary: mediasource_MP4_AACSBR_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  current_discard_padding.second.is_zero() in audio_discard_helper.cc
  media::AudioDiscardHelper::ProcessBuffers
  media::FFmpegAudioDecoder::OnNewFrame
  
Sanitizer: address (ASAN)

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

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

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 5463123977568256 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