Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Over to ted to try his hand at one of these. May end up being nothing we can do about it due to massive OOM. Matt can provide some further context on historical bugs we've encountered in this area.

This may just end up being the fuzzer gets a frame with a crazy timestamp or duration that stalls forever even in a clockless pipeline.

Usually timeouts are just that: timeouts (the latter case). In particular, the MSE MP4 parser allows for some really large collections/arrays, and iterating over those can take lots of time. Would be good to understand which case, exactly is occurring here. profiling (e.g. "perf" tool on glinux) is a great way to quickly find the hotspot that's taking lots of time in timeout cases.  If the case is something we can sanely (and in a future-proof way) limit in production code, we should do that as the fix.

Re-running the CF job, since it looks like gclient --sync cant fetch some hashes for android_sdk and is failing. Based on the stack trace it does look like just a timeout due to a really high value in a for loop.

Looks like it's just a big timeout here: https://chromium.googlesource.com/chromium/src/+/ce238c61afe98314792abcb65e089116b76ce5a8/media/formats/mp4/box_definitions.cc#1522

sample_count in this case is 4294901761, which explains the timeout. Not sure if there is something worth changing here? possibly RCHECK(>kArbitraryMaxSampleCount)?

Any Ideas here Dan?

This is almost exactly the same as  issue 874577 , which is FFmpeg's version of the same parser.

The conclusion there was WontFix, because it's actually in some sense possible to have an arbitrarily large number of frames in a trun (in particular when none of the fields are present).

We can probably impose some reasonable upper bound on the number of frames in a fragment, but I don't have a suggestion on how to compute that number.

Since we're not running out of memory here, I'm assuming that there are no fields present. We can probably avoid the timeout in that case by not entering the loop.

 Issue 876444  has been merged into this issue.

ClusterFuzz testcase 5690725480792064 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.

 Issue 895178  has been merged into this issue.