child_process: child_process.spawn ENOMEM on Windows

[bcoe]

• Version: 11
• Platform: Windows Server 2016
• Subsystem: child_process

Windows Server 2016 appears to run into memory issues when spawning multiple subprocesses.

Here's the test in question in nyc:

const path = require('path')
const assert = require('assert')
const {spawnSync} = require('child_process')
const time = process.hrtime()
const workerPath = path.join(__dirname, './cache-collision-worker.js')

function doFork (message) {
  const output = spawnSync(process.execPath, [workerPath, String(time[0]), String(time[1]), message])
  assert.equal(output.status, 0, 'received non-zero exit code ' + output.status)
}

doFork('foo')
doFork('bar')
doFork('baz')
doFork('quz')
doFork('nada')

which spawns the fairly boring subprocess:

var assert = require('assert')

var start = [
  parseInt(process.argv[2], 10),
  parseInt(process.argv[3], 10)
]

var message = process.argv[4]

var diff = process.hrtime(start)

while (diff[0] * 1e9 + diff[1] < 3e9) {
  diff = process.hrtime(start)
}


assert.strictEqual(require('./cache-collision-target')(message), message === 'nada' ? undefined :  'this is a ' + message)

//assert.strictEqual(process.env.NYC_CWD, __dirname)

which in turn requires:

module.exports = function (foo) {
  if (foo === 'foo') {
    return 'this is a foo'
  }
  if (foo === 'bar') {
    return 'this is a bar'
  }
  if (foo === 'baz') {
    return 'this is a baz'
  }
  if (foo === 'quz') {
    return 'this is a quz'
  }
}

I've tried using both spawn and spawnSync and the issue crops up in both cases. I also note that this behavior is new to Node 11 (labeled as node in the image included):

At a glance, this issue seems similar to #25382; but I note that tests run fine on Node 8 and Node 10.

@nodejs/process

[bcoe]

attempts to dig further into this issue can be found here: istanbuljs/nyc#967

[bzoz]

cc @nodejs/platform-windows

[bcoe]

I'm seeing another example of this behavior: istanbuljs/istanbuljs#307

[mhdawson]

@joaocgreis is this something you can look into?

[coreyfarrell]

We are now experiencing this issue with node.js 10.16.0 as well, 10.15.0 does not have the issue - https://travis-ci.org/coreyfarrell/nyc/builds/548133760.

@bcoe Travis-CI documentation says that Windows gets 8GB ram for testing, maybe this is just inadequate for the way they setup Windows (other stuff running)? Can we try a different CI for Windows (appveyor or another)? It does seem like memory requirements for node.js under windows is increasing with each release but maybe this is unavoidable.

[jasnell]

@bcoe ... whatcha think... does this need to remain open?

[coreyfarrell]

I just retested nyc on Travis for Windows with Node.js 8, 10, 12 and 14. I didn't receive an ENOMEM error this time. Not sure if this means that something was fixed in Node.js or if Travis increased the memory available since the last time I tried.

[bcoe]

@jasnell @coreyfarrell if we're not seeing this any longer, let's close.