detached ArrayBuffers are specced to throw often, but implementations do not

[domenic]

Previously discussed several times. @annevk brought it up 2 years ago in https://esdiscuss.org/topic/arraybuffer-neutering.

My understanding is that TC39 has decided to hope that one day implementations start throwing here. I am not aware of any implementation plans to do so, but maybe my info is out of date.

In any case, it's worth having an open tracking issue under "web reality" so that people trying to implement the ES spec realize that it doesn't match the reality of the web and implementations.

[bterlson]

Possibly relevant thread: heycam/webidl#151

[bterlson]

Possibly relevant thread: heycam/webidl#151

[anba]

It's also probably worth mentioning that all current implementations violate one or more of the invariants listed in 6.1.7.3 Invariants of the Essential Internal Methods for operations on typed arrays with detached array buffers. So it's not recommended to simply copy the bevaviour of web browsers.

[anba]

It's also probably worth mentioning that all current implementations violate one or more of the invariants listed in 6.1.7.3 Invariants of the Essential Internal Methods for operations on typed arrays with detached array buffers. So it's not recommended to simply copy the bevaviour of web browsers.

[littledan]

@anba Which invariants do you see violated? Do you have a test case? (Possibly relevant thread: tc39/test262#841)

[littledan]

@anba Which invariants do you see violated? Do you have a test case? (Possibly relevant thread: tc39/test262#841)

[anba]

One of the [[OwnPropertyKeys]] invariants is violated in all engines:

function detach(ab) {
  if (ArrayBuffer.transfer) {
    ArrayBuffer.transfer(ab);
  } else if (typeof detachArrayBuffer === "function") {
    detachArrayBuffer(ab);
  } else if (typeof transferArrayBuffer === "function") {
    transferArrayBuffer(ab)
  } else if (typeof Worker === "function") {
    try { eval("%ArrayBufferNeuter(ab)") } catch (e) {
      var w = new Worker("");
      w.postMessage(ab, [ab]);
      w.terminate();
    }
  } else {
    throw new TypeError("cannot detach array buffer");
  }
}

var ta = new Int32Array(1);

// Observe ta[0] as non-configurable.
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));

detach(ta.buffer);

// Expected: Throws TypeError
// Actual: Prints empty string
// Violates: [[OwnPropertyKeys]]
// The returned List must contain at least the keys of all non-configurable own properties that have previously been observed. 
print(Object.getOwnPropertyNames(ta));

And related to this an issue with for-in because of:

EnumerateObjectProperties must obtain the own property keys of the target object by calling its [[OwnPropertyKeys]] internal method.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must print "0" or throw.
for (var p in ta) print(p);

Violation for [[GetOwnProperty]] in V8 and SM, because non-configurable properties can disappear

If P's attributes other than [[Writable]] may change over time or if the property might disappear, then P's [[Configurable]] attribute must be true.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must not print undefined.
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));

Similar issue for [[HasProperty]] in V8/SM:

If P was previously observed as a non-configurable data or accessor own property of the target, [[HasProperty]] must return true.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must not print false.
print(0 in ta);

And also [[Delete]]:

If P was previously observed to be a non-configurable own data or accessor property of the target, [[Delete]] must return false.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must not print true.
print(delete ta[0]);

And strictly speaking typed arrays aren't even modifiable in JSC, because they're reported as non-configurable + non-writable, but that's unrelated to the detachment issue.

[anba]

One of the [[OwnPropertyKeys]] invariants is violated in all engines:

function detach(ab) {
  if (ArrayBuffer.transfer) {
    ArrayBuffer.transfer(ab);
  } else if (typeof detachArrayBuffer === "function") {
    detachArrayBuffer(ab);
  } else if (typeof transferArrayBuffer === "function") {
    transferArrayBuffer(ab)
  } else if (typeof Worker === "function") {
    try { eval("%ArrayBufferNeuter(ab)") } catch (e) {
      var w = new Worker("");
      w.postMessage(ab, [ab]);
      w.terminate();
    }
  } else {
    throw new TypeError("cannot detach array buffer");
  }
}

var ta = new Int32Array(1);

// Observe ta[0] as non-configurable.
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));

detach(ta.buffer);

// Expected: Throws TypeError
// Actual: Prints empty string
// Violates: [[OwnPropertyKeys]]
// The returned List must contain at least the keys of all non-configurable own properties that have previously been observed. 
print(Object.getOwnPropertyNames(ta));

And related to this an issue with for-in because of:

EnumerateObjectProperties must obtain the own property keys of the target object by calling its [[OwnPropertyKeys]] internal method.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must print "0" or throw.
for (var p in ta) print(p);

Violation for [[GetOwnProperty]] in V8 and SM, because non-configurable properties can disappear

If P's attributes other than [[Writable]] may change over time or if the property might disappear, then P's [[Configurable]] attribute must be true.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must not print undefined.
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));

Similar issue for [[HasProperty]] in V8/SM:

If P was previously observed as a non-configurable data or accessor own property of the target, [[HasProperty]] must return true.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must not print false.
print(0 in ta);

And also [[Delete]]:

If P was previously observed to be a non-configurable own data or accessor property of the target, [[Delete]] must return false.

var ta = new Int32Array(1);
print(JSON.stringify(Object.getOwnPropertyDescriptor(ta, 0)));
detach(ta.buffer);
// Must not print true.
print(delete ta[0]);

And strictly speaking typed arrays aren't even modifiable in JSC, because they're reported as non-configurable + non-writable, but that's unrelated to the detachment issue.

[littledan]

Well, all that sounds like a pretty fundamental barrier to spec'ing something more likely to be web-compatible. It sounds like the violations are all coming from TypedArray elements being non-configurable--that if we make these non-configurable properties visible, the only way to get out of it later is to throw when trying to do other stuff. It wouldn't violate the invariants to make them configurable, but then throw all over the place as if they were non-configurable, right? Just a bit ugly.

[littledan]

Well, all that sounds like a pretty fundamental barrier to spec'ing something more likely to be web-compatible. It sounds like the violations are all coming from TypedArray elements being non-configurable--that if we make these non-configurable properties visible, the only way to get out of it later is to throw when trying to do other stuff. It wouldn't violate the invariants to make them configurable, but then throw all over the place as if they were non-configurable, right? Just a bit ugly.

[anba]

It seems like web-reality has shifted a bit, because at least latest Chakra and JSC seem to throw when accessing/setting indexed properties on a detached typed array.

[anba]

It seems like web-reality has shifted a bit, because at least latest Chakra and JSC seem to throw when accessing/setting indexed properties on a detached typed array.

[jswalden]

"It wouldn't violate the invariants to make them configurable, but then throw all over the place as if they were non-configurable, right? Just a bit ugly." Sounds right to me on all accounts. Seems like the only out available.

[jswalden]

"It wouldn't violate the invariants to make them configurable, but then throw all over the place as if they were non-configurable, right? Just a bit ugly." Sounds right to me on all accounts. Seems like the only out available.

[evilpie]

@anba So detached typed array indexed element access throws in release version of Chakra and JSC? Since when?

[evilpie]

@anba So detached typed array indexed element access throws in release version of Chakra and JSC? Since when?

[anba]

@evilpie I don't know if the release versions of WebKit/Safari throw an error (I've only tried the latest JSC from source), but at least Edge 38.14393.0.0 throws a TypeError when accessing elements on a detached typed array.

[anba]

@evilpie I don't know if the release versions of WebKit/Safari throw an error (I've only tried the latest JSC from source), but at least Edge 38.14393.0.0 throws a TypeError when accessing elements on a detached typed array.

[evilpie]

Considering that Edge has been shipping throwing on detached typed arrays, I plan on changing Firefox to also throw.

[evilpie]

Considering that Edge has been shipping throwing on detached typed arrays, I plan on changing Firefox to also throw.