Exit code not preserved on JS heap out of memory (134) from mocha

[mlrawlings]

Expected Behavior

nyc would exit with the same error code as its subprocess

Observed Behavior

nyc exits with 0 rather than 134 on JavaScript heap out of memory from mocha

Bonus Points! Code (or Repository) that Reproduces Issue

💻 Set up

• node 8.5.0
• nyc 11.6.0
• mocha 5.0.5

mkdir bad-exit
cd bad-exit
npm i nyc mocha
echo "var x = []; while(true) x.push({ a:'123'.repeat(1000000) });" > test.js

✅Prints 134

node --max-old-space-size=16 test.js
echo $?

✅Prints 134

mocha --max-old-space-size=16 test.js
echo $?

✅Prints 134

nyc node --max-old-space-size=16 test.js
echo $?

❌Prints 0

nyc mocha --max-old-space-size=16 test.js
echo $?

[mlrawlings]

Just tested again with [email protected] and [email protected]. This is still an issue.

[coreyfarrell]

@boneskull any thoughts on this one? I just did some debugging and it looks like foreground-child used by nyc to spawn the subprocess receives exit code=0, signal=null in the nyc mocha variant of this test. mocha is using process.kill(process.pid, signal) but I don't think this actually works for SIGABRT. Further if it did work this would likely cause an extra core dump, maybe mocha could follow the same scheme used by foreground-child to set a proper exit code for signals?

https://github.com/tapjs/foreground-child/blob/master/index.js#L68-L70

[boneskull]

thanks, foreground-child looks useful, and certainly more robust than Mocha's solution.

complicating things is that if no signal is received, upon test failure, Mocha will exit with a nonzero code corresponding to the number of test failures. IIRC TeamCity wants this behavior for some reason; I don't know if there's a workaround. happy to revisit if someone wants to send a PR, but would strongly prefer a) not breaking TeamCity, and b) if we do need to break it, find a workaround or migration path for TeamCity + Mocha users.

[faisal3389]

Hi @mlrawlings , Were you able to find any work around for this? I'm using nyc with mocha and facing the same issue

I'm using "nyc": "^15.1.0", [email protected] and "ts-mocha": "10.0.0",

[rotu]

Found a possible culprit. [email protected] can set a malformed value as exit code and this causes the exit code to get quietly changed to 0.

The failure is not as quiet on Node >=19.

npm/cli#6766 (comment)