child_process: child_process.spawn ENOMEM on Windows

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

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

cc @nodejs/platform-windows

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

@joaocgreis

@joaocgreis is this something you can look into?

@bcoe

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.

main.yml

@bcoe

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

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.

@jasnell

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

Navigation Menu

Repository navigation

child_process: child_process.spawn ENOMEM on Windows #25484

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

child_process: child_process.spawn ENOMEM on Windows #25484

Description

Activity

bcoe commented on Jan 14, 2019

bzoz commented on Jan 17, 2019

bcoe commented on Feb 22, 2019

mhdawson commented on Feb 22, 2019

coreyfarrell commented on Jun 20, 2019

jasnell commented on Jun 25, 2020

coreyfarrell commented on Jun 26, 2020

bcoe commented on Jun 29, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions