The crash blames PostTaskAndReplyRelay::RunTaskAndPostReply() but really the problem comes when invoking Run() on what appears to be a use-after-free.

The callback template tells us this is replying with a disk_cache::SimpleBackendImpl::DiskStatResult which from code search can only be the reply to SimpleBackendImpl::InitializeIndex() from SimpleBackendImpl::InitCacheStructureOnDisk().

https://cs.chromium.org/chromium/src/net/disk_cache/simple/simple_backend_impl.cc?type=cs&q=%26SimpleBackendImpl::InitializeIndex&sq=package:chromium

Should this reply use a WeakPtr?

@tzik: any idea how we could better highlight the cause in crash (i.e. in this case we're lucky because the reply traits make it obvious but on a PostTaskAndReply with, e.g., a bool we would have no idea who's at fault...).

Thanks for the forward and the decoding. 

Hmm, the reply already uses a WeakPtr, though? 
This being recent likely means it's related to the forward direction changing from the cache thread (except this is renderer, not browser anyway..)

Also are you sure it's not in the post direction --- wouldn't the reply have RunReplyAndSelfDestruct in the backtrace? 

Hmm actually kinda wondering if DiskStatResult didn't just end up winning the merged instantiation lottery for this particular binary (62.0.3185.0)

Focusing on Windows (since Android ones don't have any info past RunTaskAndPostReply):
3188 all seem to be DxDiagNode at top frame (and IOResult below)
3187 mentions DiskStatResult on top, BlobItemBytesResponse one frame below.
3186 is DxDiagNode/VideoCaptureSettings
3185 is as you described
3184 (one report) has DxDiagNode/MhtmlSaveStatus
older ones only have android stuff.

To me this suggests that the attribution via this method is likely unreliable, so if it's correct it is by accident...

Just to update, crashes with this magic signature seems to have appeared on Windows in M-62 since chrome version:62.0.3184.0.

Link to the list of the builds on Windows:
===========================================
https://crash.corp.google.com/browse?q=custom_data.ChromeCrashProto.magic_signature_1.name%3D%27base%3A%3A%60anonymous%20namespace%5C%27%3A%3APostTaskAndReplyRelay%3A%3ARunTaskAndPostReply%27%20AND%20product.name%3D%27Chrome_Android%27&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D&unnest=#-property-selector,samplereports:5,productversion:1000.

Latest Dev(62.0.3188.4) of Windows has reported 95 crashes from 90 clients and is ranked as #12 amongst top renderer crashes. 

Note: There have been no crashes reported on the last 2 Windows canary(62.0.3190.0 and 62.0.3191.0). Marking this as Stable blocker for M-62 and for tracking.

Looked into some of them.
Some of VideoCaptureSettings cases look caused by a miscompilation or a broken binary.

On DxDiagNode and DiskStatResult cases, all I saw was posted by media::WebMediaPlayerImpl::ReportMemoryUsage according to the TaskAnnotator stack. So, these are likely a part of http://crbug.com/726532. A base::Unretained to |demuxer_| likely causes an UAF.

Retitling this to making it more obvious to people scanning who may want to look at it, per the analysis in comment #7.

|demuxer_| isn't cleared until ~WMPI at which point WeakPtrs will have been invalidated. It's guaranteed alive at this point. There are only a couple call sites that modify that value, so I don't think it's possible for the scenario in c#7 to occur.

The stack traces in that bug also point to the hasAudio() line, which just reads a member variable, so I don't think it's related to a null demuxer_.

#c12: Do we have any chance to run the posted task runs after WMPI dtor?
It looks to me that if:
 - WebMediaPlayerImpl::OnError
 - WebMediaPlayerImpl::ReportMemoryUsage
 - WebMediaPlayerImpl::~WebMediaPlayerImpl
 - Demuxer::GetMemoryUsage
are called in this order, it hits a UAF.

The returns are all bound AsWeakPtr() and ~WMPI call Pipeline::Stop() which blocks on the media thread until shutdown:

https://cs.chromium.org/chromium/src/media/base/pipeline_impl.cc?type=cs&sq=package:chromium&l=1033

By that point the post to Demuxer from ReportMemoryUsage must have completed.

If WebMediaPlayerImpl::OnError is called before ~WMPI, PipelineController::Stop is called from the OnError [1], and PipelineController gets to State::STOPPED state. So, another PipelineController::Stop in ~WMPI is a noop [2] and doesn't flush the media task runner.

[1]: https://cs.chromium.org/chromium/src/media/blink/webmediaplayer_impl.cc?l=1349
[2]: https://cs.chromium.org/chromium/src/media/filters/pipeline_controller.cc?l=250

 Issue 758935  has been merged into this issue.

Ah, thanks for your patience tzik@, yes that does seem like that is the issue then. We're not syncing the media thread if we've already stopped in error. 

=>sandersd want to pick this one up?

Issue 758139 has been merged into this issue.

Dan is out sick so I'll try to merge a fix for this later today.

+tguilbert whose https://chromium-review.googlesource.com/c/chromium/src/+/612204 added the code to OnError where we stop the pipeline there now. Previously it always ran in the destructor and thus we didn't have this issue.

https://chromium-review.googlesource.com/c/chromium/src/+/644147 should fix it, but if not we may need to revert the change to Stop() during error.

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

commit 8a62813291c54988b34a4c49e8ed3ce535f95f97
Author: Dale Curtis <dalecurtis@chromium.org>
Date: Thu Aug 31 00:35:53 2017

Don't collect demuxer memory usage after pipeline stop.

We can't rely on Pipeline::Stop() to cycle the media thread in this
case, so the demuxer may be destroyed before use.

BUG= 755381 
TEST=new unittest

Change-Id: I5c78eaccb8f2f59dd724a891f853c3269f4a07d6
Reviewed-on: https://chromium-review.googlesource.com/644147
Reviewed-by: Thomas Guilbert <tguilbert@chromium.org>
Commit-Queue: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498696}
[modify] https://crrev.com/8a62813291c54988b34a4c49e8ed3ce535f95f97/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/8a62813291c54988b34a4c49e8ed3ce535f95f97/media/blink/webmediaplayer_impl_unittest.cc

[Auto-generated comment by a script] We noticed that this issue is targeted for M-62; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-62 label, otherwise remove Merge-TBD label. Thanks.