Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/c9d88eed628119f4e55e44cf3bb5ea2385f6356a ([parser] Move literal initialization to parser).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

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

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

Minimized repro:

(function () {
  return { __proto__: null, __proto__: 1 }
})()

Assigning to cbruni, I see this failure even with my patch reverted.

This should be a syntax error... we don't allow duplicate __proto__ fields in object literals: https://tc39.github.io/ecma262/#sec-__proto__-property-names-in-object-initializers

Oh yeah, my bad, it is a syntax error before my CL. Back to me :)

This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/9128e8bf1b01000552499ab7b2e2da161761281b

commit 9128e8bf1b01000552499ab7b2e2da161761281b
Author: Leszek Swirski <leszeks@chromium.org>
Date: Tue Dec 19 14:50:19 2017

[ignition] Move object/array literal init to bytecode gen

Move the object and array literal flag and depth initialization to when
they are visited by the bytecode generator. This avoids issues with
doing this initialization before we know whether the (syntactic) literal
is actually a literal value or a destructuring assignment.

Bug:  chromium:795922 
Bug:  v8:7178 
Change-Id: I022178ab4bc9e71f80560f3b78a759d95d4d0584
Reviewed-on: https://chromium-review.googlesource.com/833882
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50204}
[modify] https://crrev.com/9128e8bf1b01000552499ab7b2e2da161761281b/src/ast/ast.h
[modify] https://crrev.com/9128e8bf1b01000552499ab7b2e2da161761281b/src/interpreter/bytecode-generator.cc
[add] https://crrev.com/9128e8bf1b01000552499ab7b2e2da161761281b/test/mjsunit/regress/regress-crbug-795922.js

No problem, thanks for fixing :)

ClusterFuzz has detected this issue as fixed in range 50203:50204.

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

Fuzzer: ochang_js_fuzzer
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: DCHECK failure
Crash Address: 
Crash State:
  !has_null_prototype() in ast.cc
  v8::internal::ObjectLiteral::InitDepthAndFlags
  ObjectLiteral
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=50167:50168
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=50203:50204

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

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

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

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot