Predator and CL did not provide any possible suspects.
Using Code Search for the file, "ArrayBuffer.h" assigning to concern owner from GIT Blame.

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

Assigning to the reviewer as the CL owner is not a Chromium account holder.

@tkent -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This is OOM. The code tries to allocate 8GB.

However, I think AudioBuffer::CreateFloat32ArrayOrNull has an issue. It should call Float32Array::CreateOrNull() instead of Float32Array::Create().

Also, ArrayBuffer.h:170 should use OOM_CRASH like ArrayBuffer.h:140.

Thanks for the analysis.  Yes, AudioBuffer::CreateFloat32ArrayOrNull should call CreateOrNull.  I'll fix this shortly.

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

commit 5480d9713d544220c84c177f52ad1852ce92abf9
Author: Raymond Toy <rtoy@chromium.org>
Date: Wed Aug 09 23:09:53 2017

Use CreateOrNull in CreateFloat32ArrayOrNull

When zero-initializing a Float32Array, use CreateOrNull instead of
Create.  We don't want to crash if we can't allocate the array.  This
matches the behavior when we're not initializing the array.  This also
preserves the contract that we should return null if we fail to create
the array.

Bug:  753291 
Test: AudioBuffer/huge-buffer.html
Change-Id: I0635030e0c732561e979dbec7e1c123a93c73ec8
Reviewed-on: https://chromium-review.googlesource.com/608823
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493172}
[add] https://crrev.com/5480d9713d544220c84c177f52ad1852ce92abf9/third_party/WebKit/LayoutTests/webaudio/AudioBuffer/huge-buffer.html
[modify] https://crrev.com/5480d9713d544220c84c177f52ad1852ce92abf9/third_party/WebKit/Source/modules/webaudio/AudioBuffer.cpp

ClusterFuzz has detected this issue as fixed in range 493136:493235.

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

Fuzzer: inferno_twister
Job Type: windows_asan_chrome
Platform Id: windows

Crash Type: CHECK failure
Crash Address: 
Crash State:
  contents.Data() in ArrayBuffer.h
  blink::AudioBuffer::CreateFloat32ArrayOrNull
  blink::AudioBuffer::AudioBuffer
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=492351:492361
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=493136:493235

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

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

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

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

commit 0c840f07720ed0ff27cd102fe7a9be5a8f499bb3
Author: Raymond Toy <rtoy@chromium.org>
Date: Thu Aug 17 22:21:59 2017

ArrayBuffer::Create should signal OOM

ArrayBuffer::Create(num_elements, element_byte_size) should signal
OOM_CRASH just like ArrayBuffer::Create(source, byte_length) does.

Bug:  753291 
Test: 
Change-Id: If43fdffd4319e6d4e1f07879b517eb3dff8f07c9
Reviewed-on: https://chromium-review.googlesource.com/610305
Reviewed-by: Kent Tamura <tkent@chromium.org>
Commit-Queue: Raymond Toy <rtoy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495350}
[modify] https://crrev.com/0c840f07720ed0ff27cd102fe7a9be5a8f499bb3/third_party/WebKit/Source/platform/wtf/typed_arrays/ArrayBuffer.h