suspected cl https://chromium.googlesource.com/v8/v8/+/a474e84181fb6b19cc8c48cab29d670bf6302ab7%5E%21/src/runtime-profiler.cc

rmcilroy@ could you please look into this.

Michi - this seems to have been triggered by https://codereview.chromium.org/2182183005 - [interpreter] Support on-stack replacement in profiler.

The NextCompilationTier looks at the code object of the shared function info and if it is an interpreter trampoline builtin then only returns Optimized for code to be optimized by TurboFan. What seems to happen here is we OSR a non-turbofan function, which causes the stack frame to be "Optimized" while the NextCompilationTier sees that the SFI still points at an interpreter trampoline.

Not sure on the best fix for this. We could pass whether the frame is interpreted to NextCompilationTier and use that in the decision, or we could swap the code entry on SFI with a different builtin when the function gets OSRed, WDYT?

I'll take a look at this.

I have a fix in mind. The repro is actually ridiculously simple ...

// Copyright 2016 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

// Flags: --ignition --ignition-osr --turbo-from-bytecode

function osr() {
  for (var i = 0; i < 50000; ++i) Math.random();
}
osr();

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

commit f00b42ae31da497b3b25fc9012cdd8897e0463c4
Author: mstarzinger <mstarzinger@chromium.org>
Date: Fri Aug 05 08:45:27 2016

[interpreter] Fix profiler when hitting OSR frame.

This fixes the runtime profiler to no longer assume that seeing an
optimized frame on the stack implies the underlying function is not
being interpreted when entered normally. This no longer holds with code
generated for OSR directly from bytecode (not installed on function).

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

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

[modify] https://crrev.com/f00b42ae31da497b3b25fc9012cdd8897e0463c4/src/runtime-profiler.cc
[modify] https://crrev.com/f00b42ae31da497b3b25fc9012cdd8897e0463c4/src/runtime-profiler.h
[add] https://crrev.com/f00b42ae31da497b3b25fc9012cdd8897e0463c4/test/mjsunit/regress/regress-crbug-632800.js

ClusterFuzz has detected this issue as fixed in range 38359:38360.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  next_tier == Compiler::OPTIMIZED in runtime-profiler.cc
  
Regressed: V8: r38158:38159
Fixed: V8: r38359:38360

Minimized Testcase (1.19 Kb): https://cluster-fuzz.appspot.com/download/AMIfv953vru_G3YragSplspLjNTHPX3aJA3UpQZ_QgP-wC121VXm004xkj0zkGn3d2874DWCx4KsFZVMjrrzGzhgOpg8BVBK-ceZsOXzNJBDSRIfDfRGhVO27CTvFqPhvSvydh1mkXnTmJ-H8ifOAGhjCc3a0__C7g?testcase_id=5158663740456960

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