This is caused by Crankshaft inlining performing implicit tier-up. Similar to problems we already discovered with TurboFan inlining. Cleaned up repro:

// Flags: --allow-natives-syntax --ignition --turbo-from-bytecode --turbo-filter=f

function f(x) { return x + 23 }
function g(x) { return f(x) + 42 }

assertEquals(23, f(0));
assertEquals(24, f(1));
assertEquals(67, g(2));
assertEquals(68, g(3));

// Optimize {g} with Crankshaft, causing {f} to be inlined.
%OptimizeFunctionOnNextCall(g);
assertEquals(65, g(0));

// Optimize {f} with TruboFan, after it has been inlined.
%OptimizeFunctionOnNextCall(f);
assertEquals(23, f(0));

The conclusion after offline discussion was to work on the real fix, which is to support mixed stacks that allow bytecode and baseline code to be active at the same time. We don't plan to provide a quick fix for this particular issue. That is fine because --ignition-staging is not yet being shipped.

ClusterFuzz has detected this issue as fixed in range 38647:38648.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_ignition_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !info->shared_info()->is_compiled() in compiler.cc
  
Regressed: V8: r38039:38040
Fixed: V8: r38647:38648

Minimized Testcase (0.32 Kb):
Download: https://cluster-fuzz.appspot.com/download/AMIfv95WDF3eUxAi4if2LkRlhZ8XpZztBwH8tOLjlJtfeNwFBYk9e0lKyXe9sNOffHmGrWgVFAyQ27jigRArgIYLXVAejFr3bgtGIfZRDR9Vl3LzLjSpGj2OX9Aile2rECDHCqpaiYo1vRouXm_upSt6nA1r-2s-cQ?testcase_id=4975268190224384
__v_2 = 1;
__v_2.__proto__.f = 1;
__v_2.__proto__.f = function() { return 1; }
function __f_3() {}
__f_3.prototype = {f: function() { return 2; }};
__v_5 = new __f_3();
try {
} catch(e) {; }
function __f_4(obj) {
  return obj.f();
}
for (var __v_3 = -1073741824; __v_3 < 4294967295; __v_3++) {
  __f_4(__v_2);
  __f_4(__v_5);
}


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.

ClusterFuzz testcase is verified as fixed, closing issue.

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

Not really fixed, just plastered over. I'll keep this open/

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

commit b52aecac7e1f05ec3a23c9732ae936a6e50252fc
Author: mstarzinger <mstarzinger@chromium.org>
Date: Wed Aug 24 14:09:31 2016

[compiler] Make Compiler::EnsureBytecode not switch tiers.

This preserves the original shared code of the underlying function when
bytecode is provided. The method in question should only ensure bytecode
is present, but should avoid switching compilation tiers of the given
function. It might be that the function was fast-tracked to baseline by
inlining without going through the interpreted tier first.

R=rmcilroy@chromium.org
TEST=mjsunit/regress/regress-crbug-635923
BUG= chromium:635923 

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

[modify] https://crrev.com/b52aecac7e1f05ec3a23c9732ae936a6e50252fc/src/compiler.cc
[add] https://crrev.com/b52aecac7e1f05ec3a23c9732ae936a6e50252fc/test/mjsunit/regress/regress-crbug-635923.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

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.