I just an issue like this recently. We end up with video frames that start at 0 then jump to ~int64_t::max(), so we end up waiting for the duration of the frames to play out and even in clockless mode that can take a long time. We already drop frames for testing, but perhaps we also need to clamp the max duration of frames. It's not like we care about a/v sync in this case. 

@#2 these initial MSE fuzzers don't play to end. They just tell the pipeline to Play() (if they get that far), and then *done*.  You're right though that later behavior variations may indeed get similar timeout as SRC=, but for slightly different reason: if playback reaches a buffered range gap and the fuzzer case doesn't handle seeking/etc on underflow, then timeout would occur.

wrt this bug -- I have a local repro. Investigating.

Looks like it halts progress after logging (loglevel VERBOSE - 10 on debug asan local build):
VERBOSE1:renderer_impl.cc(154)] Initialize: Has encrypted stream but CDM is not set.

=> xhwang@ can you fix this? If not, please assign back, hopefully with suggestion on approach to fix :)

Tentatively lowering priority to P2; I'm not sure though what Chromium without a set CDM would do in such case, so maybe this is higher pri than P2?

mmoroz: I have a general question. Do we expect tests never to timeout with fuzzer? For a simple, for a simple test that plays a 10 sec video, the fuzzer could (somehow magically) change the input video duration to be 100 seconds, causing a timeout. For another example, the fuzzer can convert a clear video into an encrypted video, causing the playback to stall because it is waiting for JavaScript to set a CDM to be able to continue. Does this mean the code or the test have a problem to be fixed?

wolenetz: That log (on renderer_impl.cc line 154) means we are seeing an encrypted stream but there's no CDM set, yet. In this case we'll set the state to be STATE_INIT_PENDING_CDM and wait. This is WAI and I am not sure what to fix...

xhwang@, yes in general we consider any timeout as a bug. Sometimes it's fine to ignore those, if it doesn't happen too often, i.e. if it is not blocking fuzzer from discovering new coverage. I understand that there are many ways to trigger timeouts in such target, and frankly I don't have a good solution.

Besides of performing sanity checks in the fuzz target code, you may consider:

a) rely on FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION definition and reject slow inputs somewhere in the media code (example from re2 target: https://cs.chromium.org/chromium/src/third_party/re2/src/re2/parse.cc?q=FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION&sq=package:chromium&l=46&dr=C)

b) we may try to increase -timeout=25 value for media fuzzers, but it wouldn't really help if timeouts are easy to discover and happen quite often


CC'ing more folks just in case if they have anything else to say.

 Issue 769205  has been merged into this issue.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

We are closing all ooms and timeouts that are unreproducible. We won't be filing such bugs in future.