Able to reproduce the issue on Windows 10, mac 10.12.6 and ubuntu 14.04 using chrome reported version #66.0.3341.0. 

Bisect Information:
=====================
Good build: 66.0.3336.0
Bad Build : 66.0.3338.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/af540e8d369aa8105e0d4700c20f9b08dca9c3f5..eaa730ff5abd585b0b629f07406df6701589e7ff

From the above change log suspecting below change
Change-Id: I712176c715d1fb2511d87892052ba9d2d8084336
Reviewed-on: https://chromium-review.googlesource.com/853120

bbudge@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-66 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

This is related to my change. What is happening is the memory allocation is rounded up to the nearest power of 2 which would be 0x80000000. My change adds room for a pointer to the allocation, which causes us to exceed 2 GiB which is the limit in partition_alloc.

I think the simplest, safest fix is to up the limit in partition_alloc.

#4: Do you mean the conceptual equivalent of:

```
kOverheadSize = sizeof(void*);  // Could change later to include other stuff
kMaxAllocation = 2 GiB + kOverheadSize;
```

? That would SGTM, I think.

I observed allocations of 2 GiB + metadata size + sizeof(void*). I'm not sure how this worked before.

Oh and I bumped it up by a full page, since these would route through AllocPages.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/865a289c75e6aeaeaea925b58262e7afb063e5ca

commit 865a289c75e6aeaeaea925b58262e7afb063e5ca
Author: Bill Budge <bbudge@chromium.org>
Date: Thu Feb 08 03:45:48 2018

[partition_alloc] Increase direct mapping size limit.

- Increase the limit by 1 allocated page. This is needed to hold
  metadata and other information for the allocation. WASM will
  round large memory allocations up to the next power of 2, and
  adding metadata will exceed the 2 GiB limit if size > 1 GiB.

Bug:  chromium:809586 
Change-Id: I8de04bac2d2fe640c6342abed3386a6501a5fe72
Reviewed-on: https://chromium-review.googlesource.com/907855
Reviewed-by: Chris Palmer <palmer@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535293}
[modify] https://crrev.com/865a289c75e6aeaeaea925b58262e7afb063e5ca/base/allocator/partition_allocator/partition_alloc.cc
[modify] https://crrev.com/865a289c75e6aeaeaea925b58262e7afb063e5ca/base/allocator/partition_allocator/partition_alloc.h

Tested this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Chrome Build 66.0.3344.0 by following the steps mentioned in the original comment.
Issue is fixed on Windows 10 and Mac OS 10.12.6, but still able to reproduce the issue on Ubuntu 14.04.

Can see memory allocated on executing the command "new WebAssembly.Memory({initial: 32767});" in Devtools -> Console in Windows 10 and Mac OS 10.12.6.
Still seeing the error message on Ubuntu 14.04 on 66.0.3344.0 build.
Attached are the screen shots for reference.

bbudge@ Can you please check and confirm the fix on Ubuntu 14.04.

Thanks..

Deleted: 809586_Windows.PNG 61.2 KB

	809586_Windows.PNG 61.2 KB View Download

Deleted: 809586_Linux.png 223 KB

	809586_Linux.png 223 KB View Download

I can't reproduce on Ubuntu on a tip of tree build:
Version 66.0.3343.0 (Developer Build) (64-bit)

However, I wasn't able to reproduce the issue before either.

The issue is also reproducible on "Google Chrome 66.0.3343.3 (Official Build) dev (64-bit) (cohort: Dev)"