Memory.prototype.grow(1) TypeArray(memory.buffer, memory.buffer.byteLength/2, memory.buffer.byteLength) RangeError

[guest271314]

try {
  const m = new WebAssembly.Memory({initial:1, maximum: 2, shared: true});
  const encoder = new TextEncoder();
  const t_0 = encoder.encode('a'.repeat(m.buffer.byteLength));
  const u8_0 = new Uint8Array(m.buffer, 0, m.byteLength);
  u8_0.set(u8_0, 0);
  m.grow(1);
  // does not throw RangeError
  const u8_m_byteLength = new Uint8Array(m.buffer.byteLength);
  const t_1 = encoder.encode('b'.repeat(m.buffer.byteLength/2));
  // throws RangeError
  const u8_1 = new Uint8Array(m.buffer, m.buffer.byteLength/2, m.buffer.byteLength);
  // we do not get here
  // u8_1.set(t_1, m.buffer.byteLength/2);
} catch (e) {
  console.error(e);
  console.trace();
} 

Chromium 86

RangeError: Invalid typed array length: 131072
    at new Uint8Array (<anonymous>)
    at <anonymous>:13:16
(anonymous) @ VM2317:17

Nightly 80

RangeError: attempting to construct out-of-bounds TypedArray on ArrayBuffer
    <anonymous> debugger eval code:12
debugger eval code:16:11

Is this specified and expected behaviour?

[guest271314]

Adjusting the code

try {
  const m = new WebAssembly.Memory({initial:1, maximum: 2, shared: true});
  const encoder = new TextEncoder();
  const t_0 = encoder.encode('a'.repeat(m.buffer.byteLength));
  const u8_0 = new Uint8Array(m.buffer, 0, m.byteLength);
  u8_0.set(u8_0, 0);
  m.grow(1);
  // does not throw RangeError
  const u8_m_byteLength = new Uint8Array(m.buffer.byteLength);
  const t_1 = encoder.encode('b'.repeat(m.buffer.byteLength/2));
  // does not throw RangeError
  const u8_1 = new Uint8Array(m.buffer, m.buffer.byteLength/2);
  // throws RangeError
  u8_1.set(t_1, m.buffer.byteLength/2);
} catch (e) {
  console.error(e);
  console.trace();
} 

Chromium 86

RangeError: offset is out of bounds
    at Uint8Array.set (<anonymous>)
    at <anonymous>:15:8
(anonymous) @ VM2376:17
console.trace
(anonymous) @ VM2376:18

Nightly 80

RangeError: source array is too long
    <anonymous> debugger eval code:14
console.trace() debugger eval code:17:11
    <anonymous> debugger eval code:17

[taralx]

You'll have much more luck opening such reports against the browser in question, not here. https://bugs.chromium.org/p/chromium/issues/list

[guest271314]

You'll have much more luck opening such reports against the browser in question, not here. https://bugs.chromium.org/p/chromium/issues/list

The question as to whether the described result is specified and intended behaviour or not should be asked to implementers?

The original goal is to test

const u8_2 = new Uint8Array(m.buffer, m.buffer.byteLength/2 -1, 2);

however that does not appear possible.

Am asking is that by design?

[taralx]

That's javascript, not webassembly, though.

[guest271314]

These issues hint at the specific subject matter, yet do not answer the question asked at OP

• What should we throw for implementation specific limits? #993
• Should it be valid to have empty Data/Element sections #910
• Data segment overlaps #897

Am using WebAssembly.Memory() with shared set to true. Outside of WASI WebAssembly is observable via JavaScript, correct?

Was any formal discussion enagaged by JavaScript, implementers and WebAssembly re this specific subject matter?

Is the output expected?

How can a implementer issue be filed when the specification does not state, or does not refer to the expected behaviour?

Asking a very simple question that might have a very complicated answer, nonetheless, ask anyway to address the WebAssembly side of the issue - unless this is not an issue and clearly defined, where if that is the case, why?

[guest271314]

Will file an issue with JavaScript. Although implementers do whatever they want, in this case there is consistency, leading to the question is this agreed upon behaviour?

[guest271314]

@taralx FWIW after experimenting at a 32-bit machine was able to grow() WebAssembly.Memory dynamically up until a memory allocation error is thrown wasmerio/wasmer-php#121 (comment).