Regression range points to 195754cf31a6f6d53a2fdf0dc41e67b69f7fbf8f. The following is an extracted repro ...

// 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

(function() {
  "use asm";
  return function() {
    for (var i = 0; i < 10; delete unresolved_name);
    with (next.hasOwnProperty(3)) var lineNumber = 274;
  }
})()();

Michi - this seems to be failing in ReduceOsrValue(Node* node). Looking at that function it doesn't seem to handle the  Linkage::kOsrAccumulatorRegisterIndex (which has the same value as kOsrContextSpillSlotIndex - so we would end up getting the context rather than the accumulator value ?).

This isn't causing the issue I'm seeing, but I'm just wondering whether we are expecting to call this reducer with the bytecode graph builder?

From what I'm seeing I think this is a mismatch between how ReduceOsrValue accesses the frame and how GetOsrValueLocation accesses it.

GetOsrValueLocation directly accesses the stack based on an offset from StandardFrameConstants::kFixedSlotCount. As such, the OsrValues in BytecodeGraphBuilder are created with an interpreter frame offset so that they point to the correct location.

ReduceOsrValue uses GetExpression, which is a virtual function which has a different implementation for InterpretedFrame vs StandardFrame - as such it expects the index to be the same as it would on a non-interpreted frame, so we end up accessing the wrong location on the stack due to the index offsetting added to OsrValues by the BytecodeGraphBuilder.

Does this seem possible Michi?

It looks like #3 this is the case - if I subtract  InterpreterFrameConstants::kExtraSlotCount from index before calling GetExpression we don't get this crash. I've uploaded a CL at:
https://codereview.chromium.org/2538823002

 Issue 669804  has been merged into this issue.

ClusterFuzz has detected this issue as fixed in range 41386:41387.

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

Fuzzer: decoder_langfuzz
Job Type: linux_asan_d8_ignition_v8_arm_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !v8::internal::FLAG_enable_slow_asserts || (object->IsJSReceiver()) in objects-i
  
Regressed: V8: r41302:41303
Fixed: V8: r41386:41387

Minimized Testcase (5.32 Kb): https://cluster-fuzz.appspot.com/download/AMIfv971ZEfts9GY_elhIj1W0NtvF0o6XzreFLxcJwPp_tKg_3KMi-KI863pcD58Ejy5mwgc7VrEHacj_6a2mQqVFRQXhcucPKqFycZP5TEd9gEQz0s2Uw7qSngOgSGLOiQa2oY_valr5dE3VOXRLr_yjNFLVn6ICg?testcase_id=5316764318826496

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.