It seems this fix:
https://chromium-review.googlesource.com/c/chromium/src/+/1281689

Causes errors in the test, starting with this build:
https://ci.chromium.org/buildbot/chromium.webkit/WebKit%20Linux%20Trusty%20MSAN/10515

dtapuska@

Could you take a look at this issue? I am not sure why the CL is affecting the layout test above. Our WebAudio layout tests simply try to pass a huge number to the AudioBuffer constructor. The previous behavior is the AudioBuffer (not ArrayBuffer) constructor can see the result of TypedArray allocation and it can gracefully fails when the request can't be accommodated.

https://cs.chromium.org/chromium/src/third_party/blink/renderer/modules/webaudio/audio_buffer.cc?gsn=CreateOrNull&g=0&l=191

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

commit e2e0fea643d6a20d274db71f34a712966f5fca8a
Author: Thomas Guilbert <tguilbert@chromium.org>
Date: Wed Oct 17 05:44:09 2018

Disable webaudio linux ASAN/MSAN tests

Changes expectations of the following tests for ASAN and MSAN:
- webaudio/AudioBuffer/huge-buffer.html
- webaudio/dom-exceptions.html

Bug: 896068
Change-Id: Ic2edbbed567c0f85e38931096c9cf17cea940943
Reviewed-on: https://chromium-review.googlesource.com/c/1285690
Reviewed-by: Hongchan Choi <hongchan@chromium.org>
Commit-Queue: Thomas Guilbert <tguilbert@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600292}
[modify] https://crrev.com/e2e0fea643d6a20d274db71f34a712966f5fca8a/third_party/WebKit/LayoutTests/ASANExpectations
[modify] https://crrev.com/e2e0fea643d6a20d274db71f34a712966f5fca8a/third_party/WebKit/LayoutTests/MSANExpectations

I've just finished investigating this issue.

void* ArrayBufferContents::AllocateMemoryWithFlags(size_t size,
                                                   InitializationPolicy policy,
                                                   int flags) {
  if (policy == kZeroInitialize) {
    flags |= base::PartitionAllocZeroFill;
  }
+#if defined(MEMORY_SANITIZER) || defined(ADDRESS_SANITIZER)
+  if (size >= base::kGenericMaxDirectMapped)
+    return nullptr;
+#endif
  void* data = PartitionAllocGenericFlags(
      Partitions::ArrayBufferPartition(), flags, size,
      WTF_HEAP_PROFILER_TYPE_NAME(ArrayBufferContents));
  return data;
}

PartitionAllocGenericFlags will fail if size >= 2GB.
However, memory sanitizer replaces PartitionAllocGenericFlags with its own allocator function, and returns not null when size >= 2GB.

Ok. So ArrayBufferContents supports 64 bit integers but ArrayBuffer (from the IDL point of view is 32 bit based).

As well AudioBuffer from the IDL point of view only supports AudioBufferOptions of length 32 bit.

And AudioBuffer seems to pass the number of frames around as a size_t. hongchan@ does it make sense to reduce the number_of_frames in the WebAudio code to be a uint32_t from a size_t?

AudioBuffer is used in several places in the WebAudio code, so I need to check if changing all to uint32_t makes sense for all instances.

Two more questions:

1. The frame size in IDL is `unsigned long`, so if the given value is larger than 32 bit the IDL binding layer can gate it and throw an exception. No?

2. So this crash will not be observed in a regular build? It only happens on ASAN/MSAN? (as described in #7)

> However, memory sanitizer replaces PartitionAllocGenericFlags with its own allocator function, and returns not null when size >= 2GB.