Reduced repro:

===============================
// Flags: --allow-natives-syntax

var t = 0;
function foo() {
  var o = {x:1};
  var p = {y:2.5, x:0};
  o = [];
  for (var i = 0; i < 2; ++i) {
    t = o.x;
    o = p;
  }
}
foo();
foo();
%OptimizeFunctionOnNextCall(foo);
foo();
===============================

The problem is that there's a LoadField[x] that loads from an offset outside the virtual object, and therefore we don't have a replacement for the LoadField.

Fixing this as discussed offline last week.

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

commit 7201bad99d16c0e4e9f33ebc14ddb80446b06a51
Author: bmeurer <bmeurer@chromium.org>
Date: Mon Oct 31 06:43:04 2016

[turbofan] Properly deal with out-of-bounds fields in EscapeAnalysis.

Conflicting type feedback on Load/StoreICs can lead to out-of-bounds
field access, which is essentially dead code, but EscapeAnalysis was
confused about those. For now, mark the objects as escaping in these
cases, middle-term we want to deal better with this kind of compile-
time known dead code.

BUG= chromium:658185 , v8:4586 
R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2459273002
Cr-Commit-Position: refs/heads/master@{#40662}

[modify] https://crrev.com/7201bad99d16c0e4e9f33ebc14ddb80446b06a51/src/compiler/escape-analysis.cc
[add] https://crrev.com/7201bad99d16c0e4e9f33ebc14ddb80446b06a51/test/mjsunit/regress/regress-crbug-658185.js

ClusterFuzz has detected this issue as fixed in range 40661:40662.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !escape_analysis_->IsVirtual(node) in escape-analysis-reducer.cc
  
Regressed: V8: r40350:40351
Fixed: V8: r40661:40662

Minimized Testcase (0.27 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv9729pwK_Bt_OOjXRf1fxgrv_hyvSAHD7tPoNuVPeCKMUHySwz8n_NC6FvXJz5NT2lU15BUZZ0yMfa7IrdjyLyX86Q4yH-FRkvnpLW5kQR4eWnCwh3aOBvvs3YEzGaZGkCA3kGXbBjMt83pbfOH53ZOPKBECBg?testcase_id=5145103457058816
try {
} catch(e) {; }
function __f_11() {
  var __v_14 = {x:1};
  var __v_11 = {__v_11:2.5, x:0};
  __v_14 = [];
  for (var __v_12 = 0; __v_12 < 2; __v_12++) {
    __v_13 = __v_14.x + 3;
    __v_14 = __v_11;
  }
}
__f_11();
__f_11();
%OptimizeFunctionOnNextCall(__f_11);
 __f_11();


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.

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