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 adding ccs based on suspected regression changelists:

Reland "[builtins] Port Object.p.toLocaleString to CSA from JS" by peter.wm.wong@gmail.com - https://chromium.googlesource.com/v8/v8/+/bce199bbe773cd73c651e3e74e965a417f3110cc

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

Can someone can make me the owner, so I can start looking at this by accessing the test case?

Thanks!

Can't make you an owner, the owner must be a project member. Assigning to jgruber instead.
Of course you can still be the one providing a fix :)

The reproducer is:
    "" + {
      toString: Object.prototype.toLocaleString
    };

Local bisect confirms that this was introduced with this CL:
[bce199bbe773cd73c651e3e74e965a417f3110cc] Reland "[builtins] Port Object.p.toLocaleString to CSA from JS"

Before that CL, the error is:

test.js:1: RangeError: Maximum call stack size exceeded
    "" + {
       ^
RangeError: Maximum call stack size exceeded
    at Object.toLocaleString (native)
    at Object.toLocaleString (native)
    at Object.toLocaleString (native)
[...]

Thanks for the reproducing test case.
A fix is in-flight: https://chromium-review.googlesource.com/c/v8/v8/+/838854

I wonder if this is a general problem with recursive calls involving TFJ builtins, since they don't have stack checks in general.

It might even be possible to construct such TFJ-only recursive call chains in general by exploiting e.g. ToString and Symbol.toPrimitive.

Perhaps all TFJ builtins should include stack checks implicitly. +bmeurer +ishell

I like the idea, that way we are safe in general. Can you prototype this to estimate what the performance impact is? Also the question is where should this common functionality live? Do the CSA stack checks generate the same instruction sequence as the ones generated by TurboFan (i.e. do they get turned into a single machine instruction on ia32/x64 as well)?

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

commit bd1f8050b0cf82c0f64bd51bdd30e6f2a0627e0b
Author: peterwmwong <peter.wm.wong@gmail.com>
Date: Thu Dec 21 14:24:02 2017

[builtins] Add Object#toLocaleString stack check

Fixes a regression causing a seg fault instead of the
expected stack overflow.

Bug:  chromium:796427 ,  v8:6005 
Change-Id: Ifc752a4009a25f447f5e87745dcc1bb83722c34e
Reviewed-on: https://chromium-review.googlesource.com/838854
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50265}
[modify] https://crrev.com/bd1f8050b0cf82c0f64bd51bdd30e6f2a0627e0b/src/builtins/builtins-object-gen.cc
[add] https://crrev.com/bd1f8050b0cf82c0f64bd51bdd30e6f2a0627e0b/test/mjsunit/regress/regress-796427.js

ClusterFuzz has detected this issue as fixed in range 50264:50265.

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

Fuzzer: ochang_js_fuzzer
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffcf4250ff8
Crash State:
  v8::internal::Object::IsDescriptorArray
  v8::internal::CheckObjectType
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=50217:50218
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_d8_dbg&range=50264:50265

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

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

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