Ross, bisects to your CL

 Issue 668554  has been merged into this issue.

The older reward-topanel  issue 668554  has been merged into this one. Please manually review this issue to see if the duplicate is potentially eligible for a reward.

I can repo this on the following, but only when the function is being OSRed

var func = (function() {
  "use asm";
  return function() {
    for (var i = 0; i < 100000; delete global, i++) try {} catch (decodeURI) {}
  }
})()();

This seems to be due to r.ConvertInputsToNumber() happening on the "i < 100000" [1]. We only expect this to happen when deoptimization is disabled (hence the dummy frame states being returned). We disable deoptimization when we are compiling a "use asm" function. In the ASTGraphBuilder, when deoptimization is disabled we insert dummy frame states on checkpoints and set OSRGuard points to kAny type, which avoids the DCHECK. However, the BytecodeGraphBuilder doesn't do anything special when deoptimization is disabled (other than disable the liveness analyses - not sure why).

We can fix this either by teaching the BytecodeGraphBuilder to deal with deoptimization disabled, or to ensure that deoptimization is always enabled when compiling from bytecode. Given that once -verify-asm is enabled we shouldn't see asm code in the BytecodeGraphBuilder, I would vote for the second option (and have a CL to do this at https://codereview.chromium.org/2531683004, but I'm not sure if there are any implications to always enabling deopt here - WDYT?



[1] Note: this only happens when we are OSRing because don't know that both sides are Signed/Unsigned32 (since there is a phi with the OSRValue which is of type HeapConstant). As a result we end up in the following:
   } else if (r.OneInputCannotBe(Type::StringOrReceiver()) &&
             (r.BothInputsAre(Type::PlainPrimitive()) ||
              !(flags() & kDeoptimizationEnabled))) {

I'd also vote for deoptimization is always enabled for bytecode pipeline (actually I'm a bit surprised that this is not already enforced).

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

commit 195754cf31a6f6d53a2fdf0dc41e67b69f7fbf8f
Author: rmcilroy <rmcilroy@chromium.org>
Date: Mon Nov 28 10:29:17 2016

[TurboFan] Always enable deoptimization for BytecodeGraphBuilder.

The BytecodeGraphBuilder assumes that deoptimization is always enabled,
so always enable it when compiling from bytecode.

BUG= chromium:668654 

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

[modify] https://crrev.com/195754cf31a6f6d53a2fdf0dc41e67b69f7fbf8f/src/compiler/bytecode-graph-builder.cc
[modify] https://crrev.com/195754cf31a6f6d53a2fdf0dc41e67b69f7fbf8f/src/compiler/pipeline.cc

ClusterFuzz has detected this issue as fixed in range 41302:41303.

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

Fuzzer: decoder_langfuzz
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  OpParameter<FrameStateInfo>(dummy_state).bailout_id().IsNone() in js-typed-lower
  
Regressed: V8: r41208:41209
Fixed: V8: r41302:41303

Minimized Testcase (11.10 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95jWvC-h_Dd6bb-SBej4OZZ5gqUPTqgEN5uUUOXFJBdrPhRmpD35cyatt6p2i73Vl917M7xzNjZFet4ZswaEnWGyW3eH8XetCzcApT6TVx-uzIHHxNNPNvkrozRrVz5yvPoJEKpB3LsfphhdoouOwqdqSNmkg?testcase_id=5586108093300736

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.