This is caused by mismatch in static and dynamic types - we dynamically check that a value always produces a number (based on feedback), but inlining actually produces a non-number value, so the compiler is confused (assertion failure).

This is not a security bug because:
- the compiler deterministically crashes when confused.
- the code that the compiler is confused about is unreachable (the dynamic type check will always fail).

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

commit 4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e
Author: jarin <jarin@chromium.org>
Date: Tue Apr 05 12:29:43 2016

[turbofan] Restrict types in load elimination.

In simplified numbering, we make sanity checks based on types (e.g.,
NumberSubtract should take numbers as inputs), but this can be
violated if optimization passes make types less precise.

In this CL, we fix load elimination to make sure that types are
smaller in the store -> load elimination by taking an intersection
of the load's type with the store value's type and inserting a guard
with that type. Note that the load type comes from type feedback, so
it can be disjoint from the stored value type (in that case, this
must be dead code because the map chack for the load should prevent
us from using the stored value).

BUG= chromium:599412 
LOG=n

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

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

[modify] https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e/src/compiler/load-elimination.cc
[modify] https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e/src/compiler/load-elimination.h
[modify] https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e/src/compiler/pipeline.cc
[modify] https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e/test/mjsunit/mjsunit.status
[add] https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e/test/mjsunit/regress/regress-599412.js
[modify] https://crrev.com/4142bc6bc1f5d81f2cd224bafe9cf3d8d74df90e/test/unittests/compiler/load-elimination-unittest.cc

ClusterFuzz has detected this issue as fixed in range 35258:35259.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: RUNTIME_ASSERT
Crash Address: 
Crash State:
  RepresentationChangerError: node #195:HeapConstant of kRepTagged (Constant(ADDRE
  
Regressed: V8: r34976:34977
Fixed: V8: r35258:35259

Minimized Testcase (1.23 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95tlI9jZPaR6UQqSKXe9LwK7ldjeIUADbH8ajgfhmWB-f7XU0HCjFdMPDkutuKRDG0xfwfkB_-OXUoZkrNF-nlscjP7ezKETpmygG9t7TTNMNIUhgX4uUFlu_1ScF6seEqqPIr548kJ3OWonqxgeUnStYqWlw

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.

 Issue 599071  has been merged into this issue.

 Issue 601401  has been merged into this issue.