xs OOM behavior fail-stop deterministic by design?

[dckc]

Is xs fail-stop deterministic on out-of-memory? Is this documented? If so, please point me to it; if not, please document it. (If you just want to confirm that this is by design and let the code serve as the documentation, that works for me.)

@erights asked me about this. Mark, it seems that indeed xs terminates the shared cluster: it seems that c_malloc failures result in gxDefaults.terminateSharedCluster() at https://github.com/Moddable-OpenSource/moddable/blob/public/xs/sources/xsAPI.c#L1428 by way of fxJump(the) .

A little experimentation is consistent with this reading. Using a timeout utility found via a
stackoverflow clue, I ran the js code below under the xs simulator:

~/projects/moddable/examples/js/bug1$ ~/bin/timeout -m 1000000 simulator ~/projects/moddable/build/bin/lin/debug/mc/bug1/mc.so
0
1000
2000
...
23000
MEM CPU 0.49 MEM 1055592 MAXMEM 1055592 STALE 0 MAXMEM_RSS 589536
<time name="ALL">520</time>

No exception was reported.

/* global trace */

export default function main() {
  const space = [];
  let tick = 0;
  try {
    while(tick < 2000000) {
      if (tick % 1000 == 0) {
        trace(`${tick}\n`);
      }
      space.push("nom nom nom MOAR");
      tick += 1;
    }
  } catch (oops) {
    trace(`exception: ${oops}\n`);
  }
  trace(`${tick} - done\n`);
}

[phoddie]

xs generates an exception when it cannot allocate memory needed by an operation. See, for example, the calls to fxJump in xsMemory.c.

[dckc]

These exceptions can be caught by js code? Any chance you have a moment to give an example?

I must have misread what the fxJump calls do. I thought they always led to terminating the whole txMachine.

[dckc]

For context / motivation... this is discussed in Joe-E: A Security-Oriented Subset of Java, Adrian Mettler, David Wagner, and Tyler Close; January 2010:

... an object’s invariants can be violated if an error (such as running out of memory) is encountered during execution right when the object is in a temporarily inconsistent state. In many cases, these errors can be intentionally triggered by the invoking software component, for example by allocating a lot of memory or recursing deeply to use up stack space before invoking the object under attack. If a malicious caller could catch such an error, the caller would be well-positioned to exploit the violated invariant.

[erights]

Hi @dckc , thanks for finding that awesome quote. I just added it to the end on the README of https://github.com/Agoric/proposal-oom-fails-fast/ , which I'll propose at the upcoming tc39 meeting.

[phoddie]

Yes, the exceptions may be caught by JavaScript code. The following runs out of memory quickly when run on an ESP8266 microcontrollers and generates the exception trace. It is challenging to generate the exception on a computer since memory is plentiful. ;)

try {
	let x = {};
	while (true)
		x = {x};
}
catch {
	trace("Exception!\n");
}

Of course, the host knows when it is out of memory. A host implementation could choose to terminate the virtual machine in that circumstance.

[dckc]

Oh... I suppose the timeout utility I added into the mix prevented the exception report in my experiment.

@erights it looks like xs isn't fail-stop on OOM out of the box. Better update https://github.com/Agoric/proposal-oom-fails-fast/ .

[erights]

Done, thanks.