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

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

Looks like the builtins fuzzer may have found its first real bug. Here's the repro (it even contains a 'pile of poo' emoji 💩!):

function test() {
  const re = /./imys;
  re.lastIndex = 9;
  const str = 'f\uD83D\uDCA9ba\u2603';
  let result = null;
  let exception = null;
  try {
    result = re[Symbol.replace](str, '^thb@!     $ @&"  0 0aV   "{rka');
  } catch (e) {
    exception = e;
  }
  return { result: result, re: re, exception: exception };
}
%SetForceSlowPath(false);
test();  // Run once ahead of time to compile the regexp.
const fast = test();
%SetForceSlowPath(true);
const slow = test();
%SetForceSlowPath(false);

console.log(slow.result);  // f💩ba☃
console.log(fast.result);  // ^thb@!     $ @&"  0 0aV   "{rka💩ba☃

Simplified repro:

function test() {
  const re = /./y;
  re.lastIndex = 3;
  const str = 'fg';
  return re[Symbol.replace](str, '$');
}
%SetForceSlowPath(false);
console.log(test());
%SetForceSlowPath(true);
console.log(test());

Looks like the fast path doesn't handle lastIndex correctly.

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

commit d74a9fd5957ba6930482f8f8dcc34e8c964119e1
Author: jgruber <jgruber@chromium.org>
Date: Mon Aug 20 10:25:39 2018

[regexp] Fix invalid lastIndex handling in RegExp.p[@@replace]

The RegExp replace implementation is a bit of a mess. Here, we first
try to handle parts of RegExp.p.exec, and then call directly into the
raw irregexp code (skipping RegExp.p.exec).

We got parts of this wrong: when lastIndex > string.length and the
regexp instance is sticky, two things should happen. 1. The match
should fail, and 2. lastIndex should be reset to 0. On the fast path,
we did the latter but not the former, instead running exec with a
lastIndex of 0.

This CL omits the irregexp call in this case, and defaults to a failed
match instead.

Bug:  chromium:875493 
Change-Id: I8c959610d267575e37686076a3fd5dfde322f0ca
Reviewed-on: https://chromium-review.googlesource.com/1180889
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55207}
[modify] https://crrev.com/d74a9fd5957ba6930482f8f8dcc34e8c964119e1/src/runtime/runtime-regexp.cc
[add] https://crrev.com/d74a9fd5957ba6930482f8f8dcc34e8c964119e1/test/mjsunit/regress/regress-875493.js

ClusterFuzz has detected this issue as fixed in range 584760:584761.

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

Fuzzer: libFuzzer_v8_regexp_builtins_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !ResultAreIdentical(args); RegExpBuiltinsFuzzerHash=decNUMBER in regexp-builtins
  v8::internal::CompileRunAndVerify
  v8::internal::TestRegExpPrototypeReplace
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=567310:567338
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=584760:584761

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md 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 6374859345756160 is verified as fixed, so closing issue as verified.

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