Unable to find actual suspect through code search and also observing no possible suspect CL under regression range, hence adding appropriate label and requesting someone from dev team to look in to this issue.

Thanks!

Also WebRTC.

I tried the repro tool, but is unable to reproduce.
Running: ASAN_SYMBOLIZER_PATH="/usr/local/google/home/maxmorin/.pex/code/cd4ccd3a4765253140e654a372f37ec8274b6f7e/clusterfuzz/resources/llvm-symbolizer" DISPLAY=":0.0" ASAN_OPTIONS="redzone=64:strict_string_check=1:strict_memcmp=1:allow_user_segv_handler=0:max_uar_stack_size_log=16:handle_sigfpe=1:handle_sigbus=1:detect_stack_use_after_return=1:alloc_dealloc_mismatch=0:print_scariness=1:allocator_may_return_null=1:quarantine_size_mb=10:detect_odr_violation=0:handle_sigill=1:allocator_release_to_os_interval_ms=500:coverage=0:use_sigaltstack=1:fast_unwind_on_fatal=0:detect_leaks=1:handle_segv=1:handle_abort=1:check_malloc_usable_size=0:detect_container_overflow=1:symbolize=1:print_summary=1" /usr/local/google/home/maxmorin/chromium/src/out/clusterfuzz_6434612746911744/audio_decoder_opus_fuzzer -rss_limit_mb=2048 -runs=100 -timeout=25 /usr/local/google/home/maxmorin/.clusterfuzz/cache/testcases/6434612746911744_testcase/fuzz-2
INFO: Seed: 995954342
INFO: Loaded 5 modules   (122892 guards): 465 [0x7f8cf3988008, 0x7f8cf398874c), 19097 [0x7f8cf21aeba0, 0x7f8cf21c1604), 28347 [0x7f8cf27a84a0, 0x7f8cf27c3f8c), 55471 [0x7f8cf378e110, 0x7f8cf37c43cc), 19512 [0x9ce550, 0x9e1630), 
/usr/local/google/home/maxmorin/chromium/src/out/clusterfuzz_6434612746911744/audio_decoder_opus_fuzzer: Running 1 inputs 100 time(s) each.
Running: /usr/local/google/home/maxmorin/.clusterfuzz/cache/testcases/6434612746911744_testcase/fuzz-2
Executed /usr/local/google/home/maxmorin/.clusterfuzz/cache/testcases/6434612746911744_testcase/fuzz-2 in 14 ms
***
*** NOTE: fuzzing was not performed, you have only
***       executed the target code on a fixed set of inputs.
***
New crash type: 
New crash state:
  

Original crash type: Timeout
Original crash state:
  audio_decoder_opus_fuzzer

The stacktrace doesn't match the original stacktrace.

14 ms isn't near the timeout level of 25 s. Henrik: Do you have any clue what might be going on here?

 Issue 834551  has been merged into this issue.

Should this be bumped to M69?

Yes.

I've found that the problem with these timeouts often is that the fuzzer increases the length of the fuzz data to the point that the test takes too long time to run even though no actual problems are found. I've fixed this for a few other fuzzers, e.g., in https://webrtc-review.googlesource.com/57581, by simply returning immediately if the input is too long.

ClusterFuzz has detected this issue as fixed in range 575836:575837.

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

Fuzzer: libFuzzer_audio_decoder_opus_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: Timeout (exceeds 25 secs)
Crash Address: 
Crash State:
  audio_decoder_opus_fuzzer
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=453388:453440
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=575836:575837

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

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

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