Predator could not provide any possible suspects.
Assigning to the concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/5d786be128109d0c93ff47e22845f32c66d75e17..a23a4a8ebce3ff6c73a30fc888286d342774e574?pretty=fuller&n=10000

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/c7af2f07e7458da6bab556dd3a2f2dcac3f73276

@smcgruer -- Could you please look into the issue, kindly re-assign if this has nothing to do with your changes.
Thank You.

This is definitely my change, but I'm unclear how it could be crashing. I've ran the reduced test case on Linux and it doesn't crash there, but I'll need to get a hold of a Windows machine to test on that OS.

WorkletAnimation however is a blink-feature-guarded unreleased feature, so this is not P1.

Ah, you could probably get a trace like that by running with --disable-threaded-animation with DCHECKs disabled:

smcgruer@stiglet2:~/chromium/src$ ./out/Release/content_shell --disable-threaded-animation --enable-blink-features=CompositorWorker,WebAnimationsAPI file:///usr/local/google/home/smcgruer/Downloads/virtual/threaded/fast/compositorworker/fuzz-425-worklet-animation-creation.html

DevTools listening on ws://127.0.0.1:34078/devtools/browser/22cef259-2abe-41ef-919c-7da28a7bca08
[1:1:0915/140725.984992:9166725700977:INFO:CompositorAnimationTimeline.cpp(34)] CompositorAnimationTimeline::PlayerAttached, this: (nil), client.CompositorPlayer(): 0x182fc695cf80
Received signal 11 SEGV_MAPERR 000000000000
#0 0x7f6179593e97 base::debug::StackTrace::StackTrace()
#1 0x7f61795939ff base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f617b181330 <unknown>
#3 0x7f61752839ee blink::CompositorAnimationTimeline::PlayerAttached()
#4 0x7f6174cbd9eb blink::WorkletAnimation::Create()
#5 0x7f6174abb67e blink::V8WorkletAnimation::constructorCallback()
#6 0x7f6177109256 v8::internal::FunctionCallbackArguments::Call()
#7 0x7f617719a058 v8::internal::(anonymous namespace)::HandleApiCallHelper<>()
#8 0x7f6177199af3 v8::internal::Builtin_Impl_HandleApiCall()


Looks like Animation.cpp null-checks CompositorTimeline() so I guess for now we should too.

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

commit 6e561af357a681b7e3fdc8c2b07326266aacda8c
Author: Stephen McGruer <smcgruer@chromium.org>
Date: Wed Sep 20 01:44:39 2017

Speculative fix for clusterfuzz crash in WorkletAnimation::Create

If running without threaded animation, CompositorTimeline() will be
null. We never expected anyone to run this code without threaded
animation, but I suspect that the clusterfuzz bot did so resulting in
 http://crbug.com/765706 .

Running without threaded animation is still unsupported, but this CL
does add a guard to avoid crashing in that case.

Bug:  765706 
Change-Id: Ibe0baa2074e49ae7227c7db256ef765f72219a07
Reviewed-on: https://chromium-review.googlesource.com/668999
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Stephen McGruer <smcgruer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503023}
[modify] https://crrev.com/6e561af357a681b7e3fdc8c2b07326266aacda8c/third_party/WebKit/Source/modules/compositorworker/WorkletAnimation.cpp

ClusterFuzz has detected this issue as fixed in range 503015:503032.

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

Fuzzer: ochang_domfuzzer
Job Type: windows_asan_content_shell
Platform Id: windows

Crash Type: Null-dereference READ
Crash Address: 0x00000000
Crash State:
  blink::CompositorAnimationTimeline::PlayerAttached
  blink::WorkletAnimation::Create
  blink::WorkletAnimationV8Internal::constructor
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=501271:501306
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=503015:503032

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

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 4703206428114944 is verified as fixed, so closing issue as verified.

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