The result is a list of CLs that change the crashed files. 

Author: nhiroki
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/d56a35fb25dc388a0506174b9e3fda67337313ce
Time: Thu Apr 20 01:05:33 2017
File InProcessWorkerObjectProxy.cpp is changed in this cl (and is part of stack frame #4, "StartPendingActivityTimer"; frame #5, "blink::InProcessWorkerObjectProxy::ProcessMessageFromWorkerObject")
Minimum distance from crash line to modified line: 20. (file: InProcessWorkerObjectProxy.cpp, crashed on: 150, modified: 130).

This would be the cause of  issue 713685 

Issue 714634 has been merged into this issue.

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

- Go/Fracas

Adding CHECKs for further debugging:
https://codereview.chromium.org/2846773002/

tzik@ found a possible cause in the underlying scheduler. He is now more deeply investigating how it happens. (Thank you, tzik-san!)

Looked into it.

The WorkerGlobalScopeScheduler instance was Dispose()d in this call path:
TaskQueueManager::ProcessTaskFromWorkQueue
WorkerThread::WillProcessTask()
WorkerThread::PrepareForShutdownOnWorkerThread()
WorkerGlobalScopeScheduler::Dispose()

And the crashing task ran immediately after that in the same ProcessTaskFromWorkQueue. Though the scheduler disposal cancels all following task, that seems not to cancel the about-to-run task.

Ah... interesting. Before GlobalScopeScheduler was landed, this path was working fine because PrepareForShutdownOnWorkerThread() didn't clear the task to be run but just annotated it with "DO NOT RUN". After that, this path actually clears the task and it results in the crash.

I think we could move PrepareForShutdownOnWorkerThread() call from WillProcessTask() to DidProcessTask(). I'll make a patch and test it.

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

commit 611639da9364de0f00eb0136523482a9b7b394b7
Author: nhiroki <nhiroki@chromium.org>
Date: Fri Apr 28 15:19:59 2017

Worker: Stop disposing of the global scope scheduler in WorkerThread::WillProcessTask()

When forcible termination is requested, WorkerThread::WillProcessTask() calls
PrepareForShutdownOnWorkerThread() that disposes of the global scope scheduler,
which in turn disposes of the task to be run. This results in crashes.

This CL moves PrepareForShutdownOnWorkerThread() call from WillProcessTask() to
DidProcessTask() to fix the crashes. This could still cause a crash if the
termination request is issued between DidProcessTask() and WillProcessTask()
because in the case a task runs and may access an empty handle returned by V8
API. However, such a case would be rare because generally forcible termination
is scheduled as a delayed task(*) and DidProcessTask() can have a chance to
check IsForciblyTerminated() before it's fired.

(*) Forcible termination could synchronously be called in some path, but it'll
be removed (see  issue 641846 ).

BUG= 713914 

Review-Url: https://codereview.chromium.org/2849583004
Cr-Commit-Position: refs/heads/master@{#468001}

[modify] https://crrev.com/611639da9364de0f00eb0136523482a9b7b394b7/third_party/WebKit/Source/core/workers/WorkerThread.cpp

To check if the patch is working, I started a "Fixed" task on the fuzzer dashboard.

ClusterFuzz has detected this issue as fixed in range 467999:468017.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: UNKNOWN READ
Crash Address: 0x000000000040
Crash State:
  blink::InProcessWorkerObjectProxy::ProcessMessageFromWorkerObject
  void base::internal::FunctorTraits<void
  base::internal::Invoker<base::internal::BindState<void
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=465819:465843
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=467999:468017

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


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs 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 5306069904785408 is verified as fixed, so closing issue.

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