CF points to https://codereview.chromium.org/2732823002.

Fails here: https://cs.chromium.org/chromium/src/v8/src/elements.cc?rcl=80db203bd13fee72940bd1d64a40378c6f61cb86&l=2822

Repros as follows: 
  out.gn/x64.debug/d8 --predictable test.js

===== test.js =====
Object.prototype.__defineGetter__(0, function() { throw 0xaac ; } );
var ta = new Uint32Array([1, 2, 3]);
ta.includes(1);


Camillo, PTAL if this failing DCHECK(JSObject::PrototypeHasNoElements(isolate, *receiver)); is something that we should support?

In my opinion, the DCHECK can be removed. typedarrays are integer indexed exotic objects [1]. thus, it does not access elements of prototypes [2]. For element accesses, it will return undefined if a typedarray instance does not have the element although a prototype has. so, it does not matter that a prototype has elements.

[1] https://tc39.github.io/ecma262/#sec-properties-of-typedarray-instances
[2] https://tc39.github.io/ecma262/#sec-integer-indexed-exotic-objects-getownproperty-p

ClusterFuzz has detected this issue as fixed in range 43737:43738.

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

Fuzzer: decoder_langfuzz
Job Type: linux_asan_d8_v8_arm64_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  JSObject::PrototypeHasNoElements(isolate, *receiver) in elements.cc
  
Sanitizer: address (ASAN)

Regressed: V8: 43624:43625
Fixed: V8: 43737:43738

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv97-ASOdzDH_lbpMyNQC8UbIxE52-XxaoxqHrulfJvClf8Ie5rwf-1Bmza0kPM2JII2UgWsq7WppdnIQvFwXbHOHbGGcCKbyMpGuGxfrO6QxwoH6ox11h0fy53DkwA4nOPuSrw1rpTdHLCoRyFhezUkR6SueA8lGRlg8Bd5lb-JNJohqEgO0KGIhm1GOgKk1W2RPx16KMzgwhl5YZCgBAi8XUHt0SPdZwCin1BAWSQaKSfdCEFpJqZMchO-IEhRmr0w38Tq8OREshjr-DVlG2VQHKKtpZ8n5vH-29-YEiRAb3_1ba_lAqetHUh_hzxFVv45GZMUZ7alAhWUyr9c6SNv39xuUgJ1F97ehxw02-u6oTDn_nmw?testcase_id=6045832110669824


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

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