I bisected this locally to https://chromium.googlesource.com/v8/v8/+/0f88153075bbc97d4701533454cf11a690ad7210

Slightly smaller test-case (use flags --expose-gc --invoke-weak-callbacks)
------
function __f_6() {
  this.a4 = {};
}
__v_6 = new __f_6();
__v_6.prototype = __v_6;
__v_6 = new __f_6();
gc();
gc();

buf = new ArrayBuffer(8);
__v_8 = new Int32Array(buf);
__v_9 = new Float64Array(buf);

__v_8[0] = 1;
__v_6.a4 = {a: 0};
delete __v_6.a4;
__v_6.boom = __v_9[0];
------

Jakob, it looks like it is related to the last-added fast properties deletion, because we do exactly that in the test-case.

Thanks for the bisection.

Yes, this is due to fast property deletion. What happens is that __v_6.a4 is an inobject field containing a pointer. A slot is recorded for that field. Then the |a4| property is deleted, and the |boom| property is added in the same inobject field as an unboxed double value. Then the recorded slot is visited and crashes, because the raw double is not a valid pointer.

To fix this, we have to clear recorded slots when deleting a property. There is no way to do that from CSA (and we probably don't want to implement it there), so we'll have to call the runtime. Which means stub support for fast-property deletion should be reverted; but we can implement the same logic in C++ instead.

Once we have NaN tagging for object fields, slots clearing will no longer be necessary, and the operation can be implemented in the stub again.

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

commit 6cb995b936d63ce651273ff420d3dbf80ff71f13
Author: jkummerow <jkummerow@chromium.org>
Date: Wed May 03 15:50:50 2017

Move delete-last-fast-property code from CSA to C++

When deleting the most recently added fast property from an object
by undoing its last map transition, we must clear any recorded slots.
This can only be done in C++, so this functionality must move out
of the stub.
Also update a CHECK in the JSObject verifier to allow backing stores
sticking around after such property deletions.

BUG= chromium:716912 , chromium:714981 

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

[modify] https://crrev.com/6cb995b936d63ce651273ff420d3dbf80ff71f13/src/builtins/builtins-internal-gen.cc
[modify] https://crrev.com/6cb995b936d63ce651273ff420d3dbf80ff71f13/src/objects-debug.cc
[modify] https://crrev.com/6cb995b936d63ce651273ff420d3dbf80ff71f13/src/runtime/runtime-object.cc
[add] https://crrev.com/6cb995b936d63ce651273ff420d3dbf80ff71f13/test/mjsunit/regress/regress-crbug-714981.js
[add] https://crrev.com/6cb995b936d63ce651273ff420d3dbf80ff71f13/test/mjsunit/regress/regress-crbug-716912.js

ClusterFuzz has detected this issue as fixed in range 469064:469168.

Detailed report: https://clusterfuzz.com/testcase?key=5399181373210624

Fuzzer: mbarbella_js_mutation
Job Type: mac_asan_d8
Platform Id: mac

Crash Type: UNKNOWN READ
Crash Address: 0x000000000000
Crash State:
  IsFlagSet
  InFromSpace
  CheckAndUpdateOldToNewSlot
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_d8&range=467314:467323
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_d8&range=469064:469168

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5399181373210624


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.