This was found by fuzzing libvpx (commit b8c2a4eb0c47b633096f5c428b70607e7bf8d570). This bug slows down feedback driven fuzzing of libvpx.

I reported this bug (alongside a fix) many moons ago to google.

(In reply to Jean-Yves Avenard [:jya] from comment #4) > I reported this bug (alongside a fix) many moons ago to google. Great! I'm surprised it hasn't been fixed, it took seconds to find and really slows down feedback driven fuzzing when variations make it in to the test corpus.

the problem is that within the frame recycling/allocation, if there's an OOM, that information is never passed on to the caller: so at best it will enter an infinite loop ; or it will crash. need to find that bug#

Jean-Yves, can you link your fix so we can apply it to m-c, please?

Hmm. I can't reproduce with a (mac) asan build of libvpx b8c2a4eb0c47b633096f5c428b70607e7bf8d570. Tyson, can you confirm the bug is still in libvpx e67d45d4ce92468ba193288b59093fef0a502662? That's the revision the current firefox in-tree copy is based on.

(In reply to Ralph Giles (:rillian) from comment #8) > Hmm. I can't reproduce with a (mac) asan build of libvpx > b8c2a4eb0c47b633096f5c428b70607e7bf8d570. Tyson, can you confirm the bug is > still in libvpx e67d45d4ce92468ba193288b59093fef0a502662? That's the > revision the current firefox in-tree copy is based on. Yes I can still reproduce this with libvpx at e67d45d4ce92468ba193288b59093fef0a502662

Ok. Thanks for checking.

I haven't been able to follow up on this. Maire, can someone on your team take a look?

Can I get a link to the bug report to Google? And a link to Jean-Yves' fix?

I got a reply from Jean-Yves in irc last night saying he can't find a reference to this. So I think we have to start from scratch. Comment 6 (from Jean-Yves) provides a big clue about what's happening and how to fix the problem. Anthony -- Do you need this fixed soon? IIUC this is slowing down fuzzing of VP9 decode. I can put someone on this eventually, but for WebRTC and our work, this isn't a high priority -- at least not yet. If my team takes this bug over, we'll realistically get to this toward the end of Q1 or beginning of Q2. Let me know if that's "ok" (and you want me to take this over) or if you want to put someone on it sooner; obviously Jean-Yves would be ideal to take this over. Thanks.

FWIW I am not fuzzing this at the moment. I will likely revisit is in a couple months unless it is needed earlier.

(In reply to Tyson Smith [:tsmith] (PTO until Feb 10) from comment #14) > FWIW I am not fuzzing this at the moment. I will likely revisit is in a > couple months unless it is needed earlier. Thanks, Tyson. This info helps with planning. When you are close to getting back to this, can you re-ping me (needinfo :mreavy works well for me)? I'll then huddle with Anthony to figure out who is available to fix this.

I don't think we should spend time on it now.

If you have a link to the upstream bug/patch I can take a look.

We don't have an upstream link. If you can reproduce with the ivf testcase, bisecting should be straightforward.

Is it already merged upstream? I am offering to take the patch mentioned in comment #4.

(In reply to johannkoenig from comment #19) > Is it already merged upstream? I am offering to take the patch mentioned in > comment #4. Jean-Yves can you provide details please?

Maybe this one? https://chromium-review.googlesource.com/#/c/284960/

Mass change P2 -> P3

The patch mentioned in #21 was upstreamed and part of the v1.6.0 release, merged in bug #1223692