Unable to find actual suspect through code search and also observing no CL's under regression range, hence adding appropriate label and requesting someone from Android team to look in to this issue.

Thanks!

Doesn't seem to have a regression range yet. +foolip, +mlamouri: Have either of you seen any changes go by which could have caused this?

Nothing I can think of :(

Ah, that's unfortunate, looks like CF can't find the regression range:

018-06-25 15:22:17 UTC] clusterfuzz-linux-high-end-4r78: Minimize task errored out: Unable to reproduce crash reliably, skipping minimization (crashed 3/10).
[2018-06-25 15:22:39 UTC] clusterfuzz-linux-high-end-s3xp: Regression task started.
[2018-06-25 15:27:29 UTC] clusterfuzz-linux-high-end-s3xp: Regression task in-progress: Testing r569983.
[2018-06-25 15:30:24 UTC] clusterfuzz-linux-high-end-s3xp: Regression task in-progress: Testing r569982.
[2018-06-25 15:35:09 UTC] clusterfuzz-linux-high-end-s3xp: Regression task in-progress: Testing r569981.
[2018-06-25 15:39:42 UTC] clusterfuzz-linux-high-end-s3xp: Regression task in-progress: Bad build at r517698. Skipping.
[2018-06-25 15:41:21 UTC] clusterfuzz-linux-high-end-s3xp: Regression task in-progress: Bad build at r517712. Skipping.
[2018-06-25 15:43:04 UTC] clusterfuzz-linux-high-end-s3xp: Regression task in-progress: Bad build at r517832. Skipping.
[2018-06-25 15:43:04 UTC] clusterfuzz-linux-high-end-s3xp: Regression task errored out: Unable to recover from bad build.
[2018-06-28 09:07:50 UTC] clusterfuzz-linux-high-end-zzcf: Progression task started: r571049.
[2018-06-28 09:10:59 UTC] clusterfuzz-linux-high-end-zzcf: Progression task finished.

I've attempted to redo regression range analysis; maybe it will work the 2nd time.

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/+/ffb5de3934abd4e16399b2f79e7100823c6076fd (Don't propagate cmdline flags that are not read by renderer processes.).

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.

Hmm, I think the flaky crash rate is causing CF trouble. Redoing again since I don't see anything in that change which should be responsible.

ClusterFuzz testcase 5282347281547264 appears to be flaky, updating reproducibility label.

=>back to untriaged then, will have to repro manually.

The pending activity is due to the HTMLVideoElement checking ImageLoader::HasPendingActivity() which says it has a pending error event:

https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/loader/image_loader.cc?l=728

+images folks

+yukishiino who's made recent changes to the image loader code.

and +hiroshige who wrote those lines in image loader and the ones in HTMLVideoElement for ideas.

Just FYI,

https://chromium.googlesource.com/chromium/src/+/c12550526c2bbd8c4da21d388312030a027fb567/third_party/blink/renderer/core/html/media/html_media_element.cc#3601

The failing DCHECK is checking a pending activity when an ExecutionContext is destroyed.

However, in general, "pending activity" and "availability of execution context" are orthogonal.  V8 wrapper objects (of ActiveScriptWrappable) are alive if and only if there is a pending activity *AND* an execution context is alive.  See below.

https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/bindings/active_script_wrappable_base.cc?l=15&rcl=4e06d3bb37f0f0df90285c238d4ad0a11f7b2eb7

I don't know about the original intention of the code.  I wonder if we really need this DCHECK.

Just my two cents.

Looking at https://chromium.googlesource.com/chromium/src/+/e00176037247f2b52793975bdce03118f2d1e021/third_party/WebKit/Source/core/html/HTMLMediaElement.h it seems that HTMLMediaElement used to be an ActiveDOMObject and this call happened when stop() was called.

Would it be correct to drop the DCHECK now?

I don't see a good reason to have DCHECK here.

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

commit 7261c7b6992929ff6a27dd4376310f2b3c51a584
Author: Mounir Lamouri <mlamouri@chromium.org>
Date: Fri Jul 06 04:16:30 2018

Remove stale DCHECK() in HTMLMediaElement::ContextDestroyed.

Bug:  856593 
Change-Id: I65641ffbd46452d39b08049929ca4ba744e9fc44
Reviewed-on: https://chromium-review.googlesource.com/1127146
Commit-Queue: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#572890}
[modify] https://crrev.com/7261c7b6992929ff6a27dd4376310f2b3c51a584/third_party/blink/renderer/core/html/media/html_media_element.cc