Somewhat reduced repro ...

function Module(stdlib, env, heap) {
  "use asm";
  var MEM = new stdlib.Int32Array(heap);
  function f() {
    MEM[0] = 0;
  }
  return { f: f };
}
function instantiate() {
  var buffer = new ArrayBuffer(0);
  Module(this, {}, buffer).f();
  %DebugPrint(Module);
  try {} finally {}
  gc();
  %DebugPrint(Module);
  Module(this, {}, buffer).f();
}
instantiate();

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

commit 89f839e5d0f1e1d27c637618f5763d702c9f5afd
Author: Michael Starzinger <mstarzinger@chromium.org>
Date: Mon Aug 28 15:01:30 2017

[asm.js] Correctly set minimum memory size to zero.

This makes sure the minimum memory size for WebAssembly modules derived
from asm.js is set to zero. It allows instatiation without allocating an
underlying memory, when such memory is unused. It also fixes a bug in
patching of embedded memory sizes for asm.js modules.

R=ahaas@chromium.org
TEST=mjsunit/regress/regress-crbug-759327
BUG= chromium:759327 

Change-Id: If5a965b96a03cbb5ba15bc41fbaf359f74961f41
Reviewed-on: https://chromium-review.googlesource.com/637912
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47646}
[modify] https://crrev.com/89f839e5d0f1e1d27c637618f5763d702c9f5afd/src/asmjs/asm-parser.cc
[modify] https://crrev.com/89f839e5d0f1e1d27c637618f5763d702c9f5afd/src/objects-printer.cc
[modify] https://crrev.com/89f839e5d0f1e1d27c637618f5763d702c9f5afd/src/wasm/module-decoder.h
[modify] https://crrev.com/89f839e5d0f1e1d27c637618f5763d702c9f5afd/src/wasm/wasm-module-builder.cc
[modify] https://crrev.com/89f839e5d0f1e1d27c637618f5763d702c9f5afd/src/wasm/wasm-module-builder.h
[add] https://crrev.com/89f839e5d0f1e1d27c637618f5763d702c9f5afd/test/mjsunit/regress/regress-crbug-759327.js

ClusterFuzz has detected this issue as fixed in range 497828:497874.

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

Fuzzer: mbarbella_js_mutation
Job Type: linux_ubsan_vptr_d8
Platform Id: linux

Crash Type: Null-dereference
Crash Address: 0x000000000000
Crash State:
  NULL
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=488740:489609
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_d8&range=497828:497874

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

See https://github.com/google/clusterfuzz-tools for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

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

commit 402f5151cdb20cb33bf5e2f113cb623f96c2952e
Author: Andreas Haas <ahaas@chromium.org>
Date: Tue Aug 29 07:45:27 2017

[wasm] Reset WasmCompiledModule when it contains non-default values

When we use a WasmCompiledModule for a second instance (i.e. the first
instance has been collected already by the GC), we reset all instance
specialization data the WasmCompiledModule contains, and then patch in
the new instance specialization data. However, we guarded the reset of
memory references, and in the referenced issue the memory references
were not reset and therefore later patched incorrectly during
instantiation. With this CL we change the condition and reset now every
time the current version of a WasmCompiledModule contains non-default
values.

R=mtrofin@chromium.org
CC=​mstarzinger@chromium.org
TEST=mjsunit/regress/regress-crbug-759327

Bug:  chromium:759327 
Change-Id: I9a147afd6ad4000b782850dae0b90685759c9dc7
Reviewed-on: https://chromium-review.googlesource.com/638571
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47665}
[modify] https://crrev.com/402f5151cdb20cb33bf5e2f113cb623f96c2952e/src/wasm/wasm-objects.cc

ClusterFuzz testcase 6604860698132480 is verified as fixed, so closing issue as verified.

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