Regression range points to 966355585bb3e6e21c063c2b670045f5a75e5aa5.

I was able to reduce this to a simple repro:

if (this.Worker) {
  var v = [1.3];
  v.length = 0;

  var __v_9 = new Worker('');
  __v_9.postMessage(v);
}

Seems to be failing here (value-serializer.cc:558):
        Handle<FixedDoubleArray> elements(
            FixedDoubleArray::cast(array->elements()), isolate_);

Looks like array->GetElementsKind() says it is FAST_DOUBLE_ELEMENTS, but the cast fails because array->IsFixedDoubleArray() is false.

Ah, that looks like a real (albeit very simple bug in ValueSerializer): the cast is only legal if the length is greater than zero (otherwise empty_fixed_array is used). I can send out a CL to fix this, if you'd like.

Sounds good, thanks!

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

commit c3856de3714e62943d4bed100346158c227318a4
Author: jbroman <jbroman@chromium.org>
Date: Wed Feb 01 20:25:56 2017

ValueSerializer: Check for zero length before casting to FixedDoubleArray.

Even though the elements kind is FAST_DOUBLE_ELEMENTS, if length is zero
the isolate's empty_fixed_array is used. It's illegal to cast this to
FixedDoubleArray, so we avoid the cast.

BUG= chromium:686479 

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

[modify] https://crrev.com/c3856de3714e62943d4bed100346158c227318a4/src/value-serializer.cc

ClusterFuzz has detected this issue as fixed in range 42866:42867.

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

Fuzzer: decoder_langfuzz
Job Type: linux_asan_d8_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !v8::internal::FLAG_enable_slow_asserts || (object->IsFixedDoubleArray()) in obj
  
Sanitizer: address (ASAN)

Regressed: V8: 42748:42749
Fixed: V8: 42866:42867

Reproducer Testcase: https://cluster-fuzz.appspot.com/download/AMIfv97vYDEwuPuEOFOjQowImQvKnRgQa4Zhga84ZxBXuutOrNdFXl9hu45KCc-UzyVtjbfs8cEESqw6QbUsPBCTH0zwmZPyBdjgH1XdgmuYMyCybEJ3R2fHhA4vfD0isfkKeiblMVFWZ5LprwEtG0BaC6Vs3Nw6PIY_sKPxmg_BRtwWeZfniM-_iVCTwgDVZqfDv04KvXD8aaxzNK33U0nly-KvAQZf-Y0FGwjlLg2uAeKAQA-jBBqzFxWp0xEZyMAKeQpcqDb4DUj0UmncanY6cpnRNf93ns07hcQKt-l_tOvPEgXjve9jt-4H4LE4z-lD46n7YROvPYxRGGFoTwc-uPcLLx92E8I5hY13cY8zYRMAaX55IHM?testcase_id=4565583996911616


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 4565583996911616 is verified as fixed, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.