Assigning to mstarzinger@ since Clusterfuzz bisected it to one of his CLs.

Minimized repro ...

// Flags: --verify-heap --ignition-staging

function f(o) {
  while (true) {
    x = o.y;
    (function() {});
  }
}
f({y:1.4});

The problem here is that we eliminate a write barrier due to representation types being off. It has nothing to do with Ignition nor with OSR, it just flushes out the problem. The following is set of nodes before write barrier elimination. Note that the value type is representation type "None".

#57:CheckTaggedPointer(#56:LoadField, #56:LoadField, #34:IfSuccess)  [Type: Number/None]
#61:StoreField[tagged base, 16, Any/TaggedPointer, kRepTagged|kTypeAny, FullWriteBarrier](#60:HeapConstant, #57:CheckTaggedPointer, ...)

With that the write barrier elimination concludes that the value has representation Type::TaggedSigned and subsequently marks the store as not needing a write barrier. Also note that we by now inserted the change from Float64toTagged that fixes up the representation.

#57:CheckTaggedPointer(#87:ChangeFloat64ToTagged, #56:LoadField, #34:IfSuccess)  [Type: Number/None]
#61:StoreField[tagged base, 16, Any/TaggedPointer, kRepTagged|kTypeAny, NoWriteBarrier](#60:HeapConstant, #57:CheckTaggedPointer, ...)

This hole is too deep for me to come up with simple fix. Deferring to Jaro.

Number/None is a pretty useless type (really time to nuke the useless representation axis). In the meantime we should check that the representation axis is inhabited in simplified lowering when determining the write barrier mode.

The change I'm making to add TaggedSigned and TaggedPointer to MachineRepresentations...and to use these in the write barrier decision functions -> will that help?

Ultimately yes.

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

commit 5c6719fcd21c1af25afe5e30f5c1c95803b3f7ed
Author: mstarzinger <mstarzinger@chromium.org>
Date: Wed Aug 17 11:15:25 2016

[turbofan] Remove representation axis for float64 fields.

This removes the representation axis from the type of {Load/StoreField}
operators representing a property load/store. The representation would
be narrowed to {None} which causes problems for all places where we use
the type to reason about the value representation. Instead we should
fully switch to {MachineRepresentation}. This is just a stop-gap fix.

R=jarin@chromium.org
BUG= chromium:636716 

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

[modify] https://crrev.com/5c6719fcd21c1af25afe5e30f5c1c95803b3f7ed/src/compiler/js-native-context-specialization.cc
[modify] https://crrev.com/5c6719fcd21c1af25afe5e30f5c1c95803b3f7ed/src/types.h
[modify] https://crrev.com/5c6719fcd21c1af25afe5e30f5c1c95803b3f7ed/test/cctest/types-fuzz.h

ClusterFuzz has detected this issue as fixed in range 38677:38678.

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

Fuzzer: decoder_langfuzz
Job Type: linux_asan_d8_ignition_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  heap_->mark_compact_collector()->IsMarked(object) in mark-compact.cc
  
Regressed: V8: r38359:38360
Fixed: V8: r38677:38678

Minimized Testcase (10.55 Kb): https://cluster-fuzz.appspot.com/download/AMIfv94cqooWlGT7bW-eurNaweSFmBvt43AX4vsqMj39RG2dHJEDKwn9g-gGY6YKj3rNWu1pCpqHJtjBdjWnjcdL0EKqTlTdQbnwS5vzURbM1FDj8Y6iokAYkzCqgJHj5WnmOXm3z9qbottwcJhCZMr-oc9AO0FDGw?testcase_id=5282210209071104

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.

Landed a stop-gap fix.

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

commit 3955bce3ea030ac4116c3e7357bdfea1a3a8bf34
Author: Benedikt Meurer <bmeurer@google.com>
Date: Fri Sep 02 05:53:08 2016

Merged: [turbofan] Remove representation axis for float64 fields.

Revision: 5c6719fcd21c1af25afe5e30f5c1c95803b3f7ed

BUG= chromium:636716 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=ahaas@chromium.org

Review URL: https://codereview.chromium.org/2308463002 .

Cr-Commit-Position: refs/branch-heads/5.3@{#57}
Cr-Branched-From: 820a23aade5e74a92d794e05a0c2b3597f0da4b5-refs/heads/5.3.332@{#2}
Cr-Branched-From: 37538cb2c1b4d75c41af386cb4fedbe5566f5608-refs/heads/master@{#37308}

[modify] https://crrev.com/3955bce3ea030ac4116c3e7357bdfea1a3a8bf34/src/compiler/js-native-context-specialization.cc
[modify] https://crrev.com/3955bce3ea030ac4116c3e7357bdfea1a3a8bf34/src/types.h
[modify] https://crrev.com/3955bce3ea030ac4116c3e7357bdfea1a3a8bf34/test/cctest/types-fuzz.h

Issue 644697 has been merged into this issue.

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