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


Thank You...

This issue applies to vpx_... so it's sw decoder. Forwarding to a better
component.

codec bug, give to jrummell@ to investigate.

Tried running the test case locally. It works if more memory is allowed (-rss_limit_mb=4096).

Added some logging to see what is going on. The input is 10 bytes (0xF000009D012A80BAF0F0). This results in a VideoDecoderConfig of:
  codec: vp8
  format: 4
  profile: vp9 profile0
  coded size: [56,8]
  visible rect: [0,0,56,8]
  natural size: [45,45]
  has extra data? false
  encryption scheme: Unencrypted
  rotation: 90°
Once decode() is called, eventually vp8_alloc_frame_buffers() is called for a frame of size 14,976 x 12,528. I logged 5 calls to allocate 284,075,520 bytes, which is 1420 Mb. With everything else this probably causes the 2048 Mb memory to be exhausted.

So it is possible that this can be fixed by specifying more memory for the test. However, I'm not sure what the actual limit should be. How big can the frame be?

Did a bit more digging. Video height and width set in vp8_peek_si_internal(), and the values are 14 bits long. So looks like the largest frame would be 16,384 x 16,384, only a little bigger than the values seen in this test case.

Will update the test to specify more memory.

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

commit 5cf1517ad927293ad81cef8a18eb4c308080cd53
Author: John Rummell <jrummell@chromium.org>
Date: Thu Jun 14 18:40:10 2018

Increase memory size for media_vpx_video_decoder_fuzzer

The maximum frame size in VP8 is 16,384 x 16,384, which uses most of the
default 2048 Mb allowed. Bumping up the size to 4096 Mb to handle the larger
frame size.

BUG= 808775 
TEST=fuzzer test case passes

Change-Id: I8e1e56bbd0936e745792f34106c7e638ff5a1c2b
Reviewed-on: https://chromium-review.googlesource.com/1100004
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Commit-Queue: John Rummell <jrummell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567355}
[modify] https://crrev.com/5cf1517ad927293ad81cef8a18eb4c308080cd53/media/BUILD.gn

+mmoroz since I thought he didn't want us doing that IIRC.

Yeah, I think I saw the question on clusterfuzz-dev@chromium.org list about that, and metzman@ replied that this option will not be used by the fuzzing infrastructure.

Even if we wanted to use it, we would have to upgrade all the bots, as right now they have less that 4GB of RAM each.

Also, MSan has a significant memory overhead compared to other sanitizers, so it's fine to WontFix OOMs reported with MSan.

I'll revert the CL.

Wow, gerrit doesn't let me to quickly land it, as the original CL was landed more than a day ago: https://chromium-review.googlesource.com/c/chromium/src/+/1104826

I need an LGTM then, or feel free to revert yourself and I'll abandon mine.

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

commit 08b5f6f48fb5ba43d01a713fb724ab8dd67acf55
Author: Max Moroz <mmoroz@chromium.org>
Date: Mon Jun 18 22:53:43 2018

Revert "Increase memory size for media_vpx_video_decoder_fuzzer"

This reverts commit 5cf1517ad927293ad81cef8a18eb4c308080cd53.

Reason for revert: this change won't work as explained in https://bugs.chromium.org/p/chromium/issues/detail?id=808775#c9 and on clusterfuzz-dev@chromium.org

Original change's description:
> Increase memory size for media_vpx_video_decoder_fuzzer
> 
> The maximum frame size in VP8 is 16,384 x 16,384, which uses most of the
> default 2048 Mb allowed. Bumping up the size to 4096 Mb to handle the larger
> frame size.
> 
> BUG= 808775 
> TEST=fuzzer test case passes
> 
> Change-Id: I8e1e56bbd0936e745792f34106c7e638ff5a1c2b
> Reviewed-on: https://chromium-review.googlesource.com/1100004
> Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
> Commit-Queue: John Rummell <jrummell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#567355}

TBR=jrummell@chromium.org,chcunningham@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  808775 
Change-Id: I47d8005442d6b81dcd023a1071e344c2e09304e5
Reviewed-on: https://chromium-review.googlesource.com/1104826
Reviewed-by: Max Moroz <mmoroz@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: John Rummell <jrummell@chromium.org>
Commit-Queue: Max Moroz <mmoroz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568209}
[modify] https://crrev.com/08b5f6f48fb5ba43d01a713fb724ab8dd67acf55/media/BUILD.gn

Closing this as WontFix since the input bytes specify a really large frame that takes a lot of memory (see comment #5). Since the decoder assumes it will be decoding into the size specified, there is not much that can be done if the bots don't have enough memory.

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