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/+/1e56813f48c74c88679c7c3f74612f2aedf1011a ([runtime] Add fast-paths for common conversion methods).

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

Looks like a bug in RegExp.p[@@replace]. I'll have a look.

Smaller repro:

var customRegexp = {
  get global() {
    return true;
  },
  get lastIndex() {
    return 4294967296;
  },
  set lastIndex(i) {},
  get unicode() {
    return true;
  },
  get exec() {
    return function () {
      return proxy;
    };
  }
};

proxy = new Proxy([""], {});

RegExp.prototype[Symbol.replace].call(customRegexp);


---------------------------------------------------------


RegExpUtils::SetAdvancedStringIndex(...) converts to a uint while the checks in RegExpUtils::AdvanceStringIndex are doing only unsigned checks on the signed input.

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

commit 3f8d6f60746e2f7e2418311845eca2118734adf7
Author: jgruber <jgruber@chromium.org>
Date: Tue Jan 09 12:03:55 2018

[regexp] Properly handle large values in AdvanceStringIndex

There were two separate bugs here. First, a signed/unsigned mismatch
where we took the result of PositiveNumberToUint32 and treated it as a
signed int. Second, AdvanceStringIndex did not handle large input
values correctly.

Both are fixed by using uint64_t consistently.

Bug:  chromium:799813 ,  v8:7258 
Change-Id: If2819f87986d0ca732bc24df290f6dc7614083e8
Reviewed-on: https://chromium-review.googlesource.com/854272
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50432}
[modify] https://crrev.com/3f8d6f60746e2f7e2418311845eca2118734adf7/src/conversions-inl.h
[modify] https://crrev.com/3f8d6f60746e2f7e2418311845eca2118734adf7/src/conversions.h
[modify] https://crrev.com/3f8d6f60746e2f7e2418311845eca2118734adf7/src/regexp/regexp-utils.cc
[modify] https://crrev.com/3f8d6f60746e2f7e2418311845eca2118734adf7/src/regexp/regexp-utils.h
[modify] https://crrev.com/3f8d6f60746e2f7e2418311845eca2118734adf7/src/runtime/runtime-regexp.cc
[add] https://crrev.com/3f8d6f60746e2f7e2418311845eca2118734adf7/test/mjsunit/regress/regress-799813.js

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

This will hit Canary tonight. Let's wait until tomorrow to verify the change in Canary, and then we can decide on merge.

ClusterFuzz has detected this issue as fixed in range 50431:50432.

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

Fuzzer: ochang_js_fuzzer
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: DCHECK failure
Crash Address: 
Crash State:
  index >= 0 && index < length() in string-inl.h
  v8::internal::String::Get
  v8::internal::RegExpUtils::AdvanceStringIndex
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=41855:41856
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=50431:50432

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

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

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

+awhalley@

The NextAction date has arrived: 2018-01-11

First thing Tuesday morning PDT, please check for any crashes/problem reports from Canary. If it looks good then we should merge.

Setting NextAction again as a reminder.

The NextAction date has arrived: 2018-01-16

#16: As far as I can tell there's nothing suspicious on the current canary.

https://crash.corp.google.com/browse?q=product.name%3D%27Chrome%27%20AND%20product.version%3D%2765.0.3322.0%27%20AND%20custom_data.ChromeCrashProto.channel%3D%27canary%27%20AND%20custom_data.ChromeCrashProto.ptype%3D%27renderer%27&sql_dialect=googlesql&ignore_case=false&enable_rewrite=true&omit_field_name=&omit_field_value=&omit_field_opt=%3D#magicsignature:1000

+cc current V8 stability sheriff.

abdulsyed@ - good for 64

Ah one thing I realized is that this is affecting Linux only, and no Canary for linux. Can we please confirm in today's Dev release? New Linux Dev version should be available this afternoon, PDT time.

#21 neither the bug nor the fix are platform-specific. (I suppose the exact repro might differ on 32/64bit due to different Smi ranges.)

Looking at the newest linux dev reports (65.0.3322.3), nothing suspicious there either.

Please merge this today before 3:00PM PST

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

commit 45535857bb4e6eb7b71cd9e550b4de01c4ee3db8
Author: jgruber <jgruber@chromium.org>
Date: Thu Jan 18 08:28:52 2018

Merged: [regexp] Properly handle large values in AdvanceStringIndex

There were two separate bugs here. First, a signed/unsigned mismatch
where we took the result of PositiveNumberToUint32 and treated it as a
signed int. Second, AdvanceStringIndex did not handle large input
values correctly.

Both are fixed by using uint64_t consistently.

NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
TBR=cbruni@chromium.org

Bug:  chromium:799813 ,  v8:7258 
Change-Id: If2819f87986d0ca732bc24df290f6dc7614083e8
Reviewed-on: https://chromium-review.googlesource.com/854272
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#50432}
Reviewed-on: https://chromium-review.googlesource.com/873031
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/branch-heads/6.4@{#74}
Cr-Branched-From: 0407506af3d9d7e2718be1d8759296165b218fcf-refs/heads/6.4.388@{#1}
Cr-Branched-From: a5fc4e085ee543cb608eb11034bc8f147ba388e1-refs/heads/master@{#49724}
[modify] https://crrev.com/45535857bb4e6eb7b71cd9e550b4de01c4ee3db8/src/conversions-inl.h
[modify] https://crrev.com/45535857bb4e6eb7b71cd9e550b4de01c4ee3db8/src/conversions.h
[modify] https://crrev.com/45535857bb4e6eb7b71cd9e550b4de01c4ee3db8/src/regexp/regexp-utils.cc
[modify] https://crrev.com/45535857bb4e6eb7b71cd9e550b4de01c4ee3db8/src/regexp/regexp-utils.h
[modify] https://crrev.com/45535857bb4e6eb7b71cd9e550b4de01c4ee3db8/src/runtime/runtime-regexp.cc
[add] https://crrev.com/45535857bb4e6eb7b71cd9e550b4de01c4ee3db8/test/mjsunit/regress/regress-799813.js

#24: Sorry, only saw the approval this morning. Merged now.

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