I think the right way to handle this situation is to always allocate a new buffer (that points to the old memory, but with a new size) and to detach the old buffer. Otherwise the use of trap handlers is semantically observable from JS.

An update on this issue, as this is blocking  issue #776119 . I have a CL that allocates a new buffer with the same backing store instead of setting byteLength (https://chromium-review.googlesource.com/c/v8/v8/+/722225), but that seems to cause issues in which the buffer gets invalidated independent of Grow in debug builds when trap handlers are enabled. Still tracking down what actually causes that to happen. 

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

commit edb75db259f1f57368567f8c7e5b205c172393e2
Author: Deepti Gandluri <gdeepti@chromium.org>
Date: Fri Dec 15 20:51:56 2017

[gin] SetProtection should return result

When SetProtection is used for wasm memory, it can fail if not enough
memory is available when growing. Fix to return the result of system
calls.

As coordination in needed between V8/Gin - this change adds a
new SetProtection method with a boolean return, subsequent changes
in V8/Chromium will swap this out to be the default SetProtection
method.

Bug:  775047 
Change-Id: I9f55d156c8317be8c012de60940d1698db439c86
Reviewed-on: https://chromium-review.googlesource.com/753429
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jeremy Roman <jbroman@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524457}
[modify] https://crrev.com/edb75db259f1f57368567f8c7e5b205c172393e2/gin/array_buffer.cc
[modify] https://crrev.com/edb75db259f1f57368567f8c7e5b205c172393e2/gin/array_buffer.h
[modify] https://crrev.com/edb75db259f1f57368567f8c7e5b205c172393e2/third_party/WebKit/Source/bindings/core/v8/V8Initializer.cpp

I think you solved that one with 
  https://chromium-review.googlesource.com/c/v8/v8/+/809165

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

commit cfb2e5e26499d985e21d16dd34ad1ad5246e6db0
Author: Deepti Gandluri <gdeepti@chromium.org>
Date: Thu Dec 21 21:49:02 2017

Revert "[gin] SetProtection should return result"

This reverts commit edb75db259f1f57368567f8c7e5b205c172393e2.

Reason for revert: Reverting this as the chromium-style errors mandate that overriding method must be marked with 'override' or 'final'. The first change needs to be in V8, will reland after the corresponding V8 change.  

Original change's description:
> [gin] SetProtection should return result
> 
> When SetProtection is used for wasm memory, it can fail if not enough
> memory is available when growing. Fix to return the result of system
> calls.
> 
> As coordination in needed between V8/Gin - this change adds a
> new SetProtection method with a boolean return, subsequent changes
> in V8/Chromium will swap this out to be the default SetProtection
> method.
> 
> Bug:  775047 
> Change-Id: I9f55d156c8317be8c012de60940d1698db439c86
> Reviewed-on: https://chromium-review.googlesource.com/753429
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jeremy Roman <jbroman@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#524457}

TBR=rmcilroy@chromium.org,jbroman@chromium.org,adamk@chromium.org,gdeepti@chromium.org,mlippautz@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  775047 
Change-Id: I4ed3f395ee357bcce4a9f7b5ac2c49c4fe47e779
Reviewed-on: https://chromium-review.googlesource.com/840145
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525818}
[modify] https://crrev.com/cfb2e5e26499d985e21d16dd34ad1ad5246e6db0/gin/array_buffer.cc
[modify] https://crrev.com/cfb2e5e26499d985e21d16dd34ad1ad5246e6db0/gin/array_buffer.h
[modify] https://crrev.com/cfb2e5e26499d985e21d16dd34ad1ad5246e6db0/third_party/WebKit/Source/bindings/core/v8/V8Initializer.cpp

I do still think we'll want to have SetProtection share it's result.
Memory exhausting is still something we'll want to feedback from to trigger a collect attempt.

Agree that we still need SetProtection to catch memory exhaustion to enable the tests that have been disabled, and avoid flakiness. 

The revert was temporary, as the first change needs to be on V8, and not Chromium.

Returning SetProtection results to catch memory exhaustion for Grow was added a few weeks ago, forgot to link this bug - https://chromium-review.googlesource.com/c/v8/v8/+/952570. Marking this as fixed.