As per the  Issue 762855  owner, assigning this issue to @dalecurtis.
@dalecurtis -- Could you please look into this issue, kindly reassign if it has nothing to do with your changes.
Thanks.

Probably WontFix; it's another MSAN related issue.

This one is weird, there are only 90 audio frames in this file and they all fail to decode. Not sure why it's timing out. It's not stuck in any spot that looks like a tight loop. Everything is single threaded here so no races that could lead to issues.

Stats show it still seems to be occurring, but CF has it tagged as unreproducible, so not sure what that means.

The track run iterator populates gazillions of sample infos. I suspect this is another case of infeasible number of output frames from a tiny mp4 file that we should add parser support for rejecting.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/356d76e89ecc9fa38632aedf2d8b306d35485bb1

commit 356d76e89ecc9fa38632aedf2d8b306d35485bb1
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Tue Oct 17 23:42:42 2017

Bail out when multiple adjacent zero sized samples are found.

Should help with fuzzing timeouts and seem like they should be
invalid... We definitely have files that have a zero sized sample
as the last sample, but none that I can find with contiguous zero
sized samples.

BUG= 770577 
TEST=fuzzer fails before allocated massive amounts of memory.

Change-Id: Ie137d6f9ec69a1afd5c496c9f6f93706d670c5d9
Reviewed-on: https://chromium-review.googlesource.com/720206
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509601}
[modify] https://crrev.com/356d76e89ecc9fa38632aedf2d8b306d35485bb1/media/formats/mp4/track_run_iterator.cc

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.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/91965df34bca6d9236e62c7a228354d17843dcfa

commit 91965df34bca6d9236e62c7a228354d17843dcfa
Author: Dan Sanders <sandersd@chromium.org>
Date: Tue Oct 24 23:29:56 2017

Limit TrackRunInfo.samples allocation size to 150MB.

When trun.sample_count is large, TrackRunInfo.samples may be allocated larger than available memory.
This CL caps that allocation to 150MB, and removes the earlier limit that disallowed two (or more)
zero-sized samples in a row.

This effectively limits the number of samples per trun to 6.5M, which also helps avoid timeouts in
fuzzing. That problem is unlikely to be solved by this CL alone, though.

Bug:  776721 , 776246 , 774760 , 776018 , 770577 
Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Ib4c35c066193a9da8ef460d9d9283e999d803ced
Reviewed-on: https://chromium-review.googlesource.com/734702
Commit-Queue: Dan Sanders <sandersd@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#511301}
[modify] https://crrev.com/91965df34bca6d9236e62c7a228354d17843dcfa/media/formats/mp4/track_run_iterator.cc

Hmm, can't repro this one. Stats for the CF issue say it still occurs, but it runs and exits instantly for me.

@mmoroz, not sure what to do about this one. I keep trying but can't repro anything (see c#10, c#5). Is there any way to get the stack trace for one of the more recent failures listed in stats?

Can't seem to reproduce this one.