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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/4484282d93e0da93befa7e04ee29343634ca5b6f (media: Make GMBVP frame delivery in order).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This crash occurs very frequently on mac platform and is likely preventing the fuzzer inferno_flicker from making much progress. Fixing this will allow more bugs to be found.

Marking this bug as a blocker for next Beta release.

If this is incorrect, please add ClusterFuzz-Wrong label and remove the ReleaseBlock-Beta label.

The issue seems to be that after we shutdown the pool, if we create new resources and they return back, we don't remove them from the pool since we're in shutdown, but we immediately delete them.
The pool still owns them though, and might delete them again if they become stale or we get request of a videoframe of a different size.

crrev.com/c/958042 will prevent creating new frames after the pool has been shutdown.

Users experienced this crash on the following builds:

Mac Canary 67.0.3368.0 -  3.70 CPM, 20 reports, 19 clients (signature gpu::gles2::StrictIdHandler::FreeIds)
Mac Canary 67.0.3368.0 -  2.22 CPM, 12 reports, 11 clients (signature media::GpuMemoryBufferVideoFramePool::PoolImpl::GetOrCreateFrameResources)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

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

commit 9e5a9d2eccecede0e87945d2b63fb22919de6c22
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Mon Mar 12 20:07:58 2018

Abort any pending copies upon decoder Reset() and pool shutdown.

Clients don't care about these copies once they destroyed the pool;
we also don't want to waste resources copying these unused frames
after Reset().

BUG=801245,  820685 , 820944
TEST=updated tests

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: I15ccf0c5a00b14e87522f923c4ec9c93416d9342
Reviewed-on: https://chromium-review.googlesource.com/958042
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542577}
[modify] https://crrev.com/9e5a9d2eccecede0e87945d2b63fb22919de6c22/media/filters/gpu_memory_buffer_decoder_wrapper.cc
[modify] https://crrev.com/9e5a9d2eccecede0e87945d2b63fb22919de6c22/media/filters/gpu_memory_buffer_decoder_wrapper_unittest.cc
[modify] https://crrev.com/9e5a9d2eccecede0e87945d2b63fb22919de6c22/media/video/gpu_memory_buffer_video_frame_pool.cc
[modify] https://crrev.com/9e5a9d2eccecede0e87945d2b63fb22919de6c22/media/video/gpu_memory_buffer_video_frame_pool.h
[modify] https://crrev.com/9e5a9d2eccecede0e87945d2b63fb22919de6c22/media/video/gpu_memory_buffer_video_frame_pool_unittest.cc
[modify] https://crrev.com/9e5a9d2eccecede0e87945d2b63fb22919de6c22/media/video/mock_gpu_memory_buffer_video_frame_pool.cc
[modify] https://crrev.com/9e5a9d2eccecede0e87945d2b63fb22919de6c22/media/video/mock_gpu_memory_buffer_video_frame_pool.h

ClusterFuzz has detected this issue as fixed in range 542559:542577.

Detailed report: https://clusterfuzz.com/testcase?key=4763285615017984

Fuzzer: inferno_flicker
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Heap-use-after-free READ 1
Crash Address: 0x6100000d4ae8
Crash State:
  media::GpuMemoryBufferVideoFramePool::PoolImpl::GetOrCreateFrameResources
  media::GpuMemoryBufferVideoFramePool::PoolImpl::StartCopy
  media::GpuMemoryBufferVideoFramePool::PoolImpl::BindAndCreateMailboxesHardwareFr
  
Sanitizer: address (ASAN)

Recommended Security Severity: High

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=542242:542269
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=542559:542577

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4763285615017984

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4763285615017984 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+awhalley@ for M67 merge review. 

Why did sheriffbot request merge for this? It was fixed long ago before branch...

RE #21: awhalley@ is aware of it and contacted mbarbella@.

Removing "Merge-Review-67" label per comment #21.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot