Removing duplicate status based on comments 6 and 7 from issue 596719.

Looks like a simple bug: in src/js/messages.js , there are many accessors, such as CallSiteGetMethodName , which directly call runtime functions like %CallSiteGetMethodNameRT which end up doing type checks (here, checking IsValid on a CallSite object). There should be extra checks on the JS side to test for incorrect receiver types and return a prettier error, if we want to handle this the way the rest of the JS natives do it.

If that's the only place where we call directly from JS into the runtime, then that sounds like the thing to do. Is this isn't something you can get to soon, then reverting the RUNTIME_ASSERT change would be a good short-term fix.

Uploaded a patch to https://codereview.chromium.org/1831053003/.

Even if we weren't going to fix it, I don't know why we'd revert the RUNTIME_ASSERT change--that change doesn't change any behavior in release mode; it only makes more things get printed to the command line in debug mode.

Thanks, mbarbella, for ensuring that these checks are done by ClusterFuzz so that we can catch errors like this!

Thanks for the patch. The reason would be to remove undue noise from the ClusterFuzz sheriffing rotation.

ClusterFuzz has detected this testcase as flaky and is unable to reproduce it in the original crash revision. Skipping fixed testing check and marking it as potentially fixed.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=4728035244244992

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_v8_mipsel_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  call_site.IsValid() in src/runtime/runtime-internal.cc
  
Regressed: V8: r34400:34401

Minimized Testcase (0.13 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv9619oJRf3WLS1ubnVIV6JEcutgdsDFByxiDlSKFSnZnH90Z9SUowEFFHPN7IhL3eCs8XniTt5TRzef-M6Ettl1jWAaARW3uKyr0lGQuQUae-dgRM96MglxogEoTYRTuDTUDjFrtA8KQD92qgXSQZeKXEuaMfA
try {
} catch(e) {; }
Error.prepareStackTrace = function(e, frames) { return frames; }
 new Error().stack[0].getMethodName.call({}); 


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

The report from c#8 is caused by another CF change related to this. They won't be detected as CHECK failures anymore (but rather as RUNTIME_ASSERTs), and when bugs are filed they won't be tagged with Stability-Crash or Pri-1.

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

commit 97fce6214e946ad5c1e09656a0317308a75f3dc3
Author: littledan <littledan@chromium.org>
Date: Fri Mar 25 02:08:44 2016

Check for proper types from error handling code

A bug in error printing meant that we failed to do proper type checks
before calling into C++ code, which could lead to RUNTIME_ASSERT
failures if methods are called on alternative receivers. This patch
adds the right type checks.

BUG= chromium:596718 
LOG=Y
R=adamk

Review URL: https://codereview.chromium.org/1831053003

Cr-Commit-Position: refs/heads/master@{#35069}

[modify] https://crrev.com/97fce6214e946ad5c1e09656a0317308a75f3dc3/src/js/messages.js
[modify] https://crrev.com/97fce6214e946ad5c1e09656a0317308a75f3dc3/src/messages.h
[modify] https://crrev.com/97fce6214e946ad5c1e09656a0317308a75f3dc3/test/cctest/interpreter/bytecode_expectations/ForOf.golden
[add] https://crrev.com/97fce6214e946ad5c1e09656a0317308a75f3dc3/test/mjsunit/regress/regress-596718.js

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

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