Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.

Thank You...

Was going to look at another one of these soon, so can take this one.

+mmoroz, any tips on debugging this? msan isn't printing anything other than oom?

Tracing with printfs and LOG(ERROR) shows that it seems to be running out of memory while freeing data. I think msan tracking overhead is too much in this case.

It doesn't appear to be allocating all that much, just a single ~550mb block, it then hits a decode error, and while shutting down the decoder and releasing memory we run out of memory.

[1204/145517.195806:ERROR:media_log.cc(310)] Estimating WebM block duration to be 63ms for the last (Simple)Block in the Cluster for this Track. Use BlockGroups with BlockDurations at the end of each Track in a Cluster to avoid estimation.
[1204/145517.197271:ERROR:audio_renderer_impl.cc(95)] ~AudioRendererImpl
[1204/145517.197593:ERROR:decoder_stream.cc(66)] DecoderStream<video>
[1204/145517.197874:ERROR:decoder_stream.cc(105)] Initialize<video>
[1204/145517.198118:ERROR:vpx_video_decoder.cc(130)] VpxVideoDecoder: 0x711000001040
[1204/145517.198620:ERROR:vpx_video_decoder.cc(313)] No pool... 0x711000001040
[1204/145517.200260:ERROR:vpx_video_decoder.cc(269)] New pool 0x711000001040
[1204/145517.200683:ERROR:decoder_stream.cc(285)] OnDecoderSelected<video>: VpxVideoDecoder
[1204/145517.201182:ERROR:media_log.cc(310)] Selected VpxVideoDecoder for video decoding, config: codec: vp9 format: 2 profile: vp9 profile0 coded size: [240,40] visible rect: [0,0,240,40] natural size: [240,40] has extra data? false encrypted? false rotation: 0°
[1204/145517.201753:ERROR:decoder_stream.cc(125)] Read<video>
[1204/145517.201848:ERROR:decoder_stream.cc(554)] ReadFromDemuxerStream<video>
[1204/145517.202217:ERROR:decoder_stream.cc(581)] OnBufferReady<video>: 0, timestamp=7868 duration=63000 size=117 side_data_size=0 is_key_frame=1 encrypted=0 discard_padding (ms)=(0, 0)
[1204/145517.202381:ERROR:decoder_stream.cc(365)] Decode<video>
[1204/145517.202462:ERROR:decoder_stream.cc(390)] DecodeInternal<video>
[1204/145517.495547:ERROR:frame_buffer_pool.cc(64)] GetFrameBuffer : 575610655
[1204/145518.103803:ERROR:vpx_video_decoder.cc(339)] vpx_codec_decode() error: Corrupt frame detected
[1204/145518.104236:ERROR:decoder_stream.cc(427)] OnDecodeDone<video>: DecodeStatus::DECODE_ERROR
[1204/145518.104308:ERROR:decoder_stream.cc(465)] OnDecodeDone<video>: Falling back to new decoder after initial decode error.
[1204/145518.104343:ERROR:offloading_video_decoder.cc(30)] ~OffloadingVideoDecoder
[1204/145518.104376:ERROR:vpx_video_decoder.cc(135)] ~VpxVideoDecoder
==2636== ERROR: libFuzzer: out-of-memory (used: 2671Mb; limit: 2048Mb)
   To change the out-of-memory limit use -rss_limit_mb=<N>

Specifically it seems to generally oom right here:
https://cs.chromium.org/chromium/src/third_party/libvpx/source/libvpx/vp9/decoder/vp9_decoder.c?l=68

Which is an ~2mb allocation per mi_alloc_size.

+fgalligan in case he sees anything crazy happening in the decoder that I missed.

This looks similar to  crbug.com/760928   (and other bugs)

That's my initial take, but since it's OOMing during free() I was surprised.

OOMs under MSan, especially with memory-hungry targets like //media ones, are not always valid issues. Please feel free to WontFix if memory allocation calls look reasonable to you.

Thanks. I think one 500mb allocation is a bit large, but within our current resolution limits (16k x 16k), so closing this as WontFix.

It seems like there may be some underlying msan bugs here though. I.e., it seems a bit odd to be running out of memory as we free large things. I wouldn't expect allocation tracking overhead to be > 2mb (the size of the free that fails).

ClusterFuzz testcase 6714583241981952 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.