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

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

WebRTC range:

https://chromium.googlesource.com/external/webrtc/trunk/webrtc/+log/c0150c67590a15389ac86a02908610c0d84a762d..0b3ccdb7c340f313d730c60245bfe163197abbc3?pretty=fuller&n=10000

Most probable change in that range:

https://chromium.googlesource.com/external/webrtc/trunk/webrtc/+/cc31c7df49e0806f04dae190877483ba6642bd8d

Any particular reason the fuzzer is running code ranges that is two and half years old?
nisse@ you were recently looking into a potential overflow here. Can you tell if this is related?

That old revision range is odd. Maybe ask engprod?

I've tried rerunning locally on master, and can't repro:

$ ./out/Fuzzer/h264_bitstream_parser_fuzzer ~/Downloads/clusterfuzz-testcase-minimized-h264_depacketizer_fuzzer-4806956567756800 
INFO: Seed: 366320525
INFO: Loaded 1 modules   (36421 inline 8-bit counters): 36421 [0x1019260, 0x10220a5), 
INFO: Loaded 1 PC tables (36421 PCs): 36421 [0x10220a8,0x10b04f8), 
./out/Fuzzer/h264_bitstream_parser_fuzzer: Running 1 inputs 1 time(s) each.
Running: /usr/local/google/home/nisse/Downloads/clusterfuzz-testcase-minimized-h264_depacketizer_fuzzer-4806956567756800
Executed /usr/local/google/home/nisse/Downloads/clusterfuzz-testcase-minimized-h264_depacketizer_fuzzer-4806956567756800 in 186 ms
***
*** NOTE: fuzzing was not performed, you have only
***       executed the target code on a fixed set of inputs.
***

I'm a bit puzzled. Patrik, any good reason the fuzzer reports a problem and blames it on a years old cl? Any useful action on this?

Let's talk to the fuzzer maintainers.

Fuzzing is running on latest code, see "Last tested revision": 597817. Calculating regression range means it will go to older builds to see where it regressed. that is why you are seeing these 2 year old builds in regression range. for timeout, oom, usually these results are flaky, so just ignore the regression range and reproduce this on trunk. usually such bugs are there forever, but fixing them makes fuzzing efficient to find more important bugs (like security vulns, stability issues).

Re c#5, is it possible that your local machine uses some hardware acceleration that is not available on CF fuzzing VMs?

The code under test here extracts certain meta data out of the h264 bitstream, without actually decoding it. So hw acceleration shouldn't be involved.

I did fix a bug in this code recently, see https://webrtc-review.googlesource.com/101760, but that change seems unlikely to cause or heal an infinite loop.

ClusterFuzz has detected this issue as fixed in range 610291:610292.

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

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=610291:610292

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

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

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