Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Unable to find actual suspect through code search and also from the provided CL under regression range, hence adding appropriate label and leaving it as untriaged for further updates.

Thanks!

Also adding WebAssembly as component, as this is triggered by reusing a WebAssembly.Memory arraybuffer.

Attempt to create a Blob object hits the object-size check. Please help to find the right owner for this.

I think most of the test case is irrelevant - the webassembly and uint8array parts are just a red herring. I think the repro degenerates into just:

new Blob(new Array(67108864))

... and the crash is trying to allocate the vector when treating the argument a sequence<> in bindings.

haraken@ - can you delegate appropriately?

I don't have access to any information from ClusterFuzz :(

   new Blob(new Array(67108864))

doesn't cause a crash here (Linux Release build with dcheck_always_on=true). Instead, the code just hits this exception: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/NativeValueTraitsImpl.h?q=nativevaluetraitsimpl.h&sq=package:chromium&dr=CSs&l=347

For what it's worth, there was a somewhat similar case in  bug 815384 , where with a "normal" build I got the expected exceptions, but with a build configured the way clusterfuzz configured its build it did indeed crash. I don't remember if I looked into it further at that time...

I've confirmed that this is working as expected.

Firefox ellegantly reports "Error: out of memory", too.  Blink crashes in such a case so far by design.

WebAssembly is not relevant to this issue.  The following code reproduces the issue with a regular/normal build.

    new Blob(new Uint8Array(new ArrayBuffer(67108864)))

Note that the following three cases look similar, but they're different.
1) new Array(67108864)
2) new ArrayBuffer(67108864)
3) new Uint8Array(new ArrayBuffer(67108864))

In case of 1) Array, we have a quick length check at:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/bindings/core/v8/NativeValueTraitsImpl.h?rcl=6a4762ecfa1eda49d5784b1c654c48c289bb4cb7&l=348
and Blink throws an exception ellegantly.

In case of 2) ArrayBuffer, an ArrayBuffer is not an Array nor it doesn't support @@iterator, so it causes a simple type error.

In case of 3) ArrayBufferView, NativeValueTraits<IDLSequence<T>>::ConvertSequenceSlow implements the conversion algorithm of Web IDL, which uses @@iterator to scan the elements.  Since @@iterator doesn't tell the total size in advance, Blink doesn't perform the size check in early stage (unlike Array).  It simply converts elements one-by-one with @@iterator, and then it hits the upper limit of WTF::Vector and crashes.

The current policy of Blink implementation is to crash in such a case.  So, this is an expected behavior.

ClusterFuzz testcase 5963980800262144 is still reproducing on tip-of-tree build (trunk).

If this testcase was not reproducible locally or unworkable, ignore this notification and we will file another bug soon with hopefully a better and workable testcase.

Otherwise, if this is not intended to be fixed (e.g. this is an intentional crash), please add ClusterFuzz-Ignore label to prevent future bug filing with similar crash stacktrace.

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

Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  count <= MaxElementCountInBackingStore<T>() in HeapAllocator.h
  unsigned long blink::HeapAllocator::QuantizedSize<blink::ArrayBufferOrArrayBuffe
  blink::NativeValueTraits<blink::IDLSequence<blink::ArrayBufferOrArrayBufferViewO
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=473072:473106

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

See https://github.com/google/clusterfuzz-tools for more information.