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

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

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/v8/v8/+/4f2cb8fe829ea84eb4920a7e3ec30bd9f3f5e7e6 (Reland of "Store SharedFunctionInfos of a Script in a FixedArray indexed by their ID").

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

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

commit abe77c57dfe287580fc6ec796f57ebff4476e25b
Author: Jochen Eisinger <jochen@chromium.org>
Date: Thu Nov 30 09:43:27 2017

Turn DCHECKs in FindSharedFunctionInfo into CHECKs

When we try to get a function literal with an ID beyond the
last known ID we easily create out-of-bound read bugs. It's preferable
to crash in this situation.

BUG= chromium:789764 
R=marja@chromium.org

Change-Id: I4f35e9231ef6af18204bbac96df3652c3d30c29f
Reviewed-on: https://chromium-review.googlesource.com/798411
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49738}
[modify] https://crrev.com/abe77c57dfe287580fc6ec796f57ebff4476e25b/src/objects.cc

I reduced the repo to the following:
_v3 = ({ _v7 = (function outer() {
        for ([...[]][function inner() {}] in []) {
        }
      })} = {}) => {
};
_v3();

It looks like an issue with the magical trio of destructuring, arrow functions and for-in loops.

The crash happens when compiling "outer" which has the following AST at this point:
--- AST ---
FUNC at 16
. KIND 0
. SUSPEND COUNT 0
. NAME "outer"
. INFERRED NAME ""
. FOR IN at 43
. . SUSPEND COUNT 0
. . FOR at 55
. . . PROPERTY at 55
. . . . DO EXPRESSION at 48
. . . . . EXPRESSION STATEMENT at -1
. . . . . . INIT at -1
. . . . . . . VAR PROXY local[0] (0x55c047aeb320) (mode = TEMPORARY) ".result"
. . . . . . . ARRAY LITERAL at 48
. . . . . FOR OF at -1
. . . . . . SUSPEND COUNT 0
. . . . . . INIT at 52
. . . . . . . ASSIGN at 52
. . . . . . . . VAR PROXY local[2] (0x55c047aeb540) (mode = TEMPORARY) ".iterator"
. . . . . . . . GET-ITERATOR at 52
. . . . . . . . . ARRAY LITERAL at 52
. . . . . . NEXT at -1
. . . . . . . AND at -1
. . . . . . . . NOT at -1
. . . . . . . . . CALL RUNTIME _IsJSReceiver at -1
. . . . . . . . . . ASSIGN at -1
. . . . . . . . . . . VAR PROXY local[3] (0x55c047aeb570) (mode = TEMPORARY) ".result"
. . . . . . . . . . . CALL
. . . . . . . . . . . . PROPERTY at -1
. . . . . . . . . . . . . VAR PROXY local[2] (0x55c047aeb540) (mode = TEMPORARY) ".iterator"
. . . . . . . . . . . . . NAME next
. . . . . . . . CALL RUNTIME ThrowIteratorResultNotAnObject at -1
. . . . . . . . . VAR PROXY local[3] (0x55c047aeb570) (mode = TEMPORARY) ".result"
. . . . . . DONE at -1
. . . . . . . PROPERTY at -1
. . . . . . . . VAR PROXY local[3] (0x55c047aeb570) (mode = TEMPORARY) ".result"
. . . . . . . . NAME done
. . . . . . EACH at -1
. . . . . . . ASSIGN at -1
. . . . . . . . VAR PROXY local[1] (0x55c047aeb430) (mode = TEMPORARY) ".for"
. . . . . . . . PROPERTY at -1
. . . . . . . . . VAR PROXY local[3] (0x55c047aeb570) (mode = TEMPORARY) ".result"
. . . . . . . . . NAME value
. . . . . . BODY at -1
. . . . . . . EXPRESSION STATEMENT at -1
. . . . . . . . CALL RUNTIME AppendElement at -1
. . . . . . . . . VAR PROXY local[0] (0x55c047aeb320) (mode = TEMPORARY) ".result"
. . . . . . . . . VAR PROXY local[1] (0x55c047aeb430) (mode = TEMPORARY) ".for"
. . . . KEY at 56
. . . . . FUNC LITERAL at 56
. . . . . . NAME inner
. . . . . . INFERRED NAME 
. . IN at 80
. . . ARRAY LITERAL at 80
. . BODY at -1
. . . BLOCK at -1

Looks like a pre-parser vs parser issue. If I run with --no-lazy then the test passes fine. Marja, could you take a look please?

A slightly simpler repro:

a = (b = !function outer() {
            for ([][function inner() {}] in []) {}
         }) => {};
a();

This is the "LeftHandExpression in IterationStatement" syntax:

IterationStatement : for ( LeftHandSideExpression in Expression ) Statement

E.g., like this:
foo = [10, 20, 30];
for (foo[0] in {a: 0, b: 1}) { print(foo); }

Prints out:
a,20,30
b,20,30

It doesn't repro for for-of loops and I couldn't also find a repro where the inner funtion occurs somewhere else than the LeftHandSideExpression.

Even simpler repro:

a = (b = !function outer() {
  for (function inner() {}.foo in []) {}
         }) => {};
a();

And the corresponding AST (hmmm, this is really small):

FUNC at 788
. KIND 0
. SUSPEND COUNT 0
. NAME "outer"
. INFERRED NAME ""
. FOR IN at 809
. . SUSPEND COUNT 0
. . FOR at 834
. . . PROPERTY at 834
. . . . FUNC LITERAL at 814
. . . . . NAME inner
. . . . . INFERRED NAME 
. . . . NAME foo
. . IN at 841
. . . ARRAY LITERAL at 841
. . BODY at -1
. . . BLOCK at -1

Hmm, I'm seeing something weird. First we eager parser outer, but don't compile it. Then we eager parse it again.

That's not supposed to happen...

(But probably irrelevant for this bug.)

Anyway, here's what happens with the IDs:

First: ParseProgram
outer: 1
inner: 2
arrow: 3

Second: ParseFunction
outer: 3 << wat??
inner: 4

And that's why they're out of sync.

Ok, less confused now (thanks jochen@). The fix is https://chromium-review.googlesource.com/#/c/v8/v8/+/803217

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

commit 0394b713799efec02b4caf834be9858344a8c02d
Author: Marja Hölttä <marja@chromium.org>
Date: Fri Dec 01 14:12:12 2017

[parser] Fix func numbering inside for in.

BUG= chromium:789764 

Change-Id: I6a466660159721683c4979af32019d740094151b
Reviewed-on: https://chromium-review.googlesource.com/803217
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49795}
[modify] https://crrev.com/0394b713799efec02b4caf834be9858344a8c02d/src/ast/ast-traversal-visitor.h
[modify] https://crrev.com/0394b713799efec02b4caf834be9858344a8c02d/src/objects.cc
[add] https://crrev.com/0394b713799efec02b4caf834be9858344a8c02d/test/mjsunit/regress/regress-crbug-789764.js

ClusterFuzz has detected this issue as fixed in range 521290:521291.

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

Job Type: linux_asan_chrome_mp
Crash Type: UNKNOWN READ
Crash Address: 0x123400000007
Crash State:
  v8::internal::Script::FindSharedFunctionInfo
  v8::internal::Compiler::GetSharedFunctionInfo
  v8::internal::interpreter::BytecodeGenerator::AllocateDeferredConstants
  
Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=438853:439220
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=521290:521291

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

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 5044048028237824 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