Unable to find actual suspect through code search nor from the provided regression range, hence adding appropriate label for further triage.

Thanks!

The blame list ("Regressed") for WebRTC seems to be from 2016. Can we check if this timeout happens regularly, or if this was just a ClusterFuzz flake?

Philip, could you see if you're able to reproduce this?

The test case it has generated is a STAP-A packet of ~700 kB which contains 17453 NALUs. There is no freeze, but it looks like the sheer size of the test cause it to time out.

ClusterFuzz has detected this issue as fixed in range 594740:594742.

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

Fuzzer: libFuzzer_h264_depacketizer_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  h264_depacketizer_fuzzer
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=397381:397497
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=594740:594742

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

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

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