Cast assert seems scary, hiding this to let v8 sheriff to triage.

Seems to be related to  crbug.com/710844 .

The problem is that if the initial memory size is 0, we don't allocate a JSArrayBuffer. The WasmMemoryObject created for the exported memory then does not have a buffer assigned (this is the design chosen in  crbug.com/710844 ).
But the {buffer} accessor still accesses it, and DCHECKs that it is indeed a JSArrayBuffer (which fails).

Repro:
=====================================================
load('test/mjsunit/wasm/wasm-constants.js');
load('test/mjsunit/wasm/wasm-module-builder.js');

var builder = new WasmModuleBuilder();
builder.addMemory(0, 0, true);
var instance = builder.instantiate();
instance.exports.memory.buffer;
=====================================================


Maybe a better fix would be to just create an empty JSArrayBuffer (pointing to {nullptr}, size 0) if the initial size is 0? AFAICT this would match the memory size and address we are emitting in the code for the case that there is no memory.
This might also remove a lot of the existing special cases for the "no initial memory" case.

 Issue 725273  has been merged into this issue.

Agreed, I don't think there is any reason not to allocate a zero-sized ArrayBuffer.

For context, a zero-sized ArrayBuffer was not allocated because the ArrayBufferAllocator allocates a non null pointer to the backing store, and this was causing undefined behavior when patching the code on grow, and for when byteLength = NaN, figured in these cases it was safer to special case the the "no initial memory" case. I like clemensh@'s suggestion to create a dummy ArrayBuffer instead, sent out a CL that fixes this one as well as the test for 727560. 

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

commit 5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f
Author: gdeepti <gdeepti@chromium.org>
Date: Thu Jun 01 17:08:02 2017

[wasm] Fix WasmMemoryObject constructor for when a module has no initial memory

BUG= chromium:724972 

R=clemensh@chromium.org, rossberg@chromium.org

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

[modify] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/src/wasm/wasm-objects.cc
[modify] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/src/wasm/wasm-objects.h
[add] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/test/mjsunit/regress/wasm/regression-724972.js
[add] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/test/mjsunit/regress/wasm/regression-727560.js

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

commit 5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f
Author: gdeepti <gdeepti@chromium.org>
Date: Thu Jun 01 17:08:02 2017

[wasm] Fix WasmMemoryObject constructor for when a module has no initial memory

BUG= chromium:724972 

R=clemensh@chromium.org, rossberg@chromium.org

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

[modify] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/src/wasm/wasm-objects.cc
[modify] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/src/wasm/wasm-objects.h
[add] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/test/mjsunit/regress/wasm/regression-724972.js
[add] https://crrev.com/5c0baf7127cae07e1aa7dd8349eab9c4641a3b4f/test/mjsunit/regress/wasm/regression-727560.js

ClusterFuzz has detected this issue as fixed in range 45664:45665.

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

Fuzzer: inferno_js_fuzzer
Job Type: linux_asan_d8_v8_arm_dbg
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !v8::internal::FLAG_enable_slow_asserts || (object->IsJSArrayBuffer()) in object
  v8::internal::WasmMemoryObject::buffer
  v8::WebAssemblyMemoryGetBuffer
  
Sanitizer: address (ASAN)

Regressed: V8: 43658:43659
Fixed: V8: 45664:45665

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


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

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

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot