JavaScript heap out of memory in v15.0.0. #1263

josephzidell · 2020-01-02T21:05:15Z

In v15.0.0, JS runs out of memory on a relatively small project while running nyc in a docker container. In v14.1.1 it all worked fine.

Link to bug demonstration repository

This is a sensitive project and with private source control

Expected Behavior

Coverage shows

Observed Behavior

Javascript has a heap overflow

test-frontend |
test-frontend |   [] 100% (completed)
test-frontend |
test-frontend |  WEBPACK  Compiled successfully in 32137ms
test-frontend |
test-frontend |  MOCHA  Testing...
test-frontend |
test-frontend |
test-frontend | <--- Last few GCs --->
test-frontend |
test-frontend | [50:0x3172330]   138018 ms: Mark-sweep 1473.6 (1500.4) -> 1469.9 (1500.4) MB, 1653.7 / 0.1 ms  (average mu = 0.133, current mu = 0.003) allocation failure scavenge might not succeed
test-frontend | [50:0x3172330]   140149 ms: Mark-sweep 1474.3 (1500.9) -> 1470.5 (1500.9) MB, 1958.3 / 0.0 ms  (average mu = 0.107, current mu = 0.081) allocation failure scavenge might not succeed
test-frontend |
test-frontend |
test-frontend | <--- JS stacktrace --->
test-frontend |
test-frontend | ==== JS stack trace =========================================
test-frontend |
test-frontend |     0: ExitFrame [pc: 0x1374fd9]
test-frontend | Security context: 0x2a0f1cf008a1 <JSObject>
test-frontend |     1: SourceMapConsumer_allGeneratedPositionsFor [0x39a4144ed0d9] [/usr/src/app/node_modules/source-map/lib/source-map-consumer.js:~178] [pc=0x35a2ce60f67b](this=0x03f2718c0111 <BasicSourceMapConsumer map =
0x149ab65e7761>,0x2352fe700259 <Object map = 0x2d594ef7fbd1>)
test-frontend |     2: /* anonymous */(aka /* anonymous */) [0x24b0c0b9a129] [/usr/src/app/node_modules/@babel/...
test-frontend |
test-frontend | FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
test-frontend |
test-frontend | Writing Node.js report to file: report.20200102.194151.50.0.001.json
test-frontend | Node.js report completed
test-frontend |  1: 0x9da7c0 node::Abort() [node]
test-frontend |  2: 0x9db976 node::OnFatalError(char const*, char const*) [node]
test-frontend |  3: 0xb39f1e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
test-frontend |  4: 0xb3a299 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
test-frontend |  5: 0xce5635  [node]
test-frontend |  6: 0xce5cc6 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
test-frontend |  7: 0xcf1b5a v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
test-frontend |  8: 0xcf2a65 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
test-frontend |  9: 0xcf5478 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
test-frontend | 10: 0xcbbda7 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType) [node]
test-frontend | 11: 0xff1e0b v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
test-frontend | 12: 0x1374fd9  [node]
test-frontend |  ERROR  mochapack exited with code null.
test-frontend | ----------|---------|----------|---------|---------|-------------------
test-frontend | File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
test-frontend | ----------|---------|----------|---------|---------|-------------------
test-frontend | All files |       0 |        0 |       0 |       0 |                  
test-frontend | ----------|---------|----------|---------|---------|-------------------
test-frontend | npm ERR! code ELIFECYCLE
test-frontend | npm ERR! errno 1
test-frontend | npm ERR! [email protected] test:unit:coverage: `nyc vue-cli-service test:unit`
test-frontend | npm ERR! Exit status 1
test-frontend | npm ERR!
test-frontend | npm ERR! Failed at the [email protected] test:unit:coverage script.
test-frontend | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
test-frontend |
test-frontend | npm ERR! A complete log of this run can be found in:
test-frontend | npm ERR!     /root/.npm/_logs/2020-01-02T19_41_51_661Z-debug.log
test-frontend | test-frontend exited with code 1
Aborting on container exit...
make: *** [test-unit] Error 1

Troubleshooting steps

Environment Information

Using wepback + Vue.js

# paste the output here

The text was updated successfully, but these errors were encountered:

coreyfarrell · 2020-01-02T21:15:56Z

Without a demonstration of the bug from you or someone else it is unlikely we'll be able to provide assistance.

I have seen memory management changes between versions of node.js as well, might be worth trying different versions (example if you are testing with 13.5.0 then try 13.4.0 or even 13.0.0).

josephzidell · 2020-01-02T21:17:08Z

I'm using the latest stable version of node (12.14)

Unfortunately, it's a classified project

josephzidell · 2020-01-02T21:18:16Z

It worked once I set NODE_OPTIONS="--max-old-space-size=4096" which tells me there's a memory issue in v15.0.0. Does that help?

josephzidell · 2020-01-02T21:22:04Z

Sorry for the multiple comments. Another point to add is it worked fine locally by running npm ..., and only had an issue in docker (used FROM node:12.14)

coreyfarrell · 2020-01-02T21:44:56Z

This does not help me determine a cause. Using nyc in private / classified projects is perfectly fine but we still the need to be able to see the problem. If someone else experiences this issue with a public project then I'll be able to look at that public project. If not then it will be up to you to create a bug demonstration project (obviously not containing any private/classified bits).

josephzidell · 2020-01-02T21:46:59Z

For sure. And I understand the need for a reproducible error. My question is, has v15.0.0 been tested in docker?

coreyfarrell · 2020-01-02T21:51:41Z

Every commit to nyc is tested in Travis CI which uses docker to run tests in an Ubuntu guest.

josephzidell · 2020-01-02T21:59:15Z

OK. Are you running mem perf tests? How do they compare to that of v14?

coreyfarrell · 2020-01-03T00:22:57Z

We do not currently have any performance tests.

josephzidell · 2020-01-03T14:12:48Z

Gotcha. Might be a good idea to get a sense of that. v15 uses a ton more memory than v14

coreyfarrell · 2020-01-03T14:38:11Z

nyc is open-source, PR's accepted. Probably cannot be part of CI but I could see running something on the side to track.

v15 has changes to the way which source-map's are processed for coverage files which I'm sure uses more memory. I'm not sure this can be solved as those changes fix persistent issues faced by many users.

josephzidell · 2020-01-03T14:44:17Z

Would you accept a PR to the readme that addresses this potential issue? It could save other people time

coreyfarrell · 2020-01-03T15:07:19Z

We need to more clearly identify the problem first. For most users nyc 15 will be a great improvement, I don't want to discourage people from upgrading.

This brings me back to the beginning, I need information about HOW the memory is increasing and at what stages of execution. For this I need something (anything) which demonstrates the issue.

josephzidell · 2020-01-03T17:52:29Z

I can tell you the stack for reference, but unfortunately don't have the time to create a replica:
Makefile calling docker compose calling an npm script that calls nyc vue-cli-service test:unit with text and lcovonly reporters. It's a vue.js SPA, and everything is written in TS. There are about 7 spec.ts files that use mocha with webpack.

Here is the bit in package.json:

  "nyc": {
    "extends": "@istanbuljs/nyc-config-typescript",
    "reporter": ["text", "lcovonly"],
    "extension": [
      ".js",
      ".ts",
      ".vue"
    ],
    "exclude": [
      "**/*.spec.ts",
      "*.config.js",
      "**/buildin/module.js"
    ]
  }

erossignon · 2020-01-11T06:25:14Z

coreyfarrell: Without a demonstration of the bug from you or someone else it is unlikely we'll be able to provide assistance.
josephzidell : Unfortunately, it's a classified project

This may help to reproduce; The same error can be produce with the node-opcua opensource project.

$ git clone https://github.com/node-opcua/node-opcua
$ cd node-opcua
$ npm install
$ npm test
$ make coveralls

=>

npx nyc --source-map \
	--include="packages/node-opcua-*/dist/**/*.js"  \
	--exclude-after-remap=false \
	--exclude="_generated_opcua_types.ts" \
	--exclude="packages/node-opcua-types/**/*.*" \
	--exclude="packages/node-opcua-utils/**/*.*" \
	--cwd=. node packages/run_all_mocha_tests.js 
<--- Last few GCs --->
[8404:0x2eb1370]    36515 ms: Scavenge 1387.4 (1422.3) -> 1387.1 (1422.8) MB, 3.2 / 0.0 ms  (average mu = 0.103, current mu = 0.056) allocation failure 
[8404:0x2eb1370]    36519 ms: Scavenge 1387.6 (1422.8) -> 1387.2 (1423.8) MB, 3.1 / 0.0 ms  (average mu = 0.103, current mu = 0.056) allocation failure 
[8404:0x2eb1370]    36524 ms: Scavenge 1388.1 (1423.8) -> 1387.4 (1424.8) MB, 2.7 / 0.0 ms  (average mu = 0.103, current mu = 0.056) allocation failure 
<--- JS stacktrace --->
==== JS stack trace =========================================
    0: ExitFrame [pc: 0x2d7a9c95be1d]
Security context: 0x054601c1e6e9 <JSObject>
    1: SourceMapConsumer_allGeneratedPositionsFor [0xed3344fdb9] [/home/travis/build/node-opcua/node-opcua/node_modules/source-map/lib/source-map-consumer.js:~178] [pc=0x2d7a9cc581d6](this=0x0663f6d82291 <BasicSourceMapConsumer map = 0x1008fe271f91>,aArgs=0x160301d255f9 <Object map = 0x1008fe272829>)
    2: /* anonymous */(aka /* anonymous */) [0x1312b5ebe75...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x8fa090 node::Abort() [node]
 2: 0x8fa0dc  [node]
 3: 0xb00

coreyfarrell · 2020-01-11T07:12:23Z

@erossignon Your backtrace does provide a clue: SourceMapConsumer. This does not identify the cause for certain but it might point to a cause. nyc 15 puts input source maps into the coverage data, this is used to produce more accurate / consistent reports. Could you do me a favor, please revert node-opcua/node-opcua@3ab1226 then add --report none to the nyc command in the istanbul target of your Makefile:

istanbul:
        npx nyc --report none --source-map \
                --include="packages/node-opcua-*/dist/**/*.js"  \
                --exclude-after-remap=false \
                --exclude="_generated_opcua_types.ts" \
                --exclude="packages/node-opcua-types/**/*.*" \
                --exclude="packages/node-opcua-utils/**/*.*" \
                --cwd=. node packages/run_all_mocha_tests.js

Then push this so we can see how CI reacts. I want to see if the error occurs while tests are running or while generating reports.

erossignon · 2020-01-11T08:29:58Z

OK, ci is now building with --report none https://travis-ci.org/node-opcua/node-opcua/jobs/635612493

erossignon · 2020-01-11T08:58:01Z

Here is the output from the Ci log

npx nyc --report none --source-map \
		--include="packages/node-opcua-*/dist/**/*.js"  \
		--exclude-after-remap=false \
		--exclude="_generated_opcua_types.ts" \
		--exclude="packages/node-opcua-types/**/*.*" \
		--exclude="packages/node-opcua-utils/**/*.*" \
		--cwd=. node packages/run_all_mocha_tests.js 
<--- Last few GCs --->
[8465:0x2a2b370]    36876 ms: Scavenge 1388.1 (1423.8) -> 1387.3 (1423.8) MB, 5.6 / 0.0 ms  (average mu = 0.100, current mu = 0.035) allocation failure 
[8465:0x2a2b370]    36883 ms: Scavenge 1388.1 (1423.8) -> 1387.5 (1424.3) MB, 5.9 / 0.0 ms  (average mu = 0.100, current mu = 0.035) allocation failure 
[8465:0x2a2b370]    36889 ms: Scavenge 1388.3 (1424.3) -> 1388.0 (1424.8) MB, 4.5 / 0.0 ms  (average mu = 0.100, current mu = 0.035) allocation failure 
<--- JS stacktrace --->
==== JS stack trace =========================================
    0: ExitFrame [pc: 0x39d02cddbe1d]
Security context: 0x22835ed1e6e9 <JSObject>
    1: SourceMapConsumer_allGeneratedPositionsFor [0x6315ea3d711] [/home/travis/build/node-opcua/node-opcua/node_modules/source-map/lib/source-map-consumer.js:~178] [pc=0x39d02d0c8a7a](this=0x33e6cab82291 <BasicSourceMapConsumer map = 0x10a65dec791>,aArgs=0x296307409b79 <Object map = 0x10a65ded029>)
    2: /* anonymous */(aka /* anonymous */) [0x2834776030e1...

canonic-epicure · 2020-03-23T09:17:59Z

Same problem here. We are using nyc to get coverage for our test suite, which consist from 888 files at the moment (888 coverage reports).

It worked fine in nyc 13:

[09:22:05].monkey.t.js?id=examples-tasks
[09:22:05][PASS]  examples/monkey.t.js?id=examples-tasks
[09:22:05]70355 passed, 0 failed assertions took 10m 56s to complete
[09:22:17]After run tests hook
[09:22:17]Process exited with code 0
[09:22:17]Step 3/3: Sanitizing coverage report.. (Command Line)
[09:22:17]Starting: /home/dev/workspace/teamcity_agents/local1/temp/agentTmp/custom_script6744396227487940321
[09:22:17]in directory: /home/dev/workspace/teamcity_agents/local1/work/cb53652e638d467d
[09:22:17]Process exited with code 0

After uprgade to nyc 15 it started to fail with:

[00:30:20][PASS]  features/Summary.t.umd.js
[00:30:20]70373 passed, 0 failed assertions took 10m 35s to complete
[00:30:46]FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
[00:30:46]
[00:30:46]<--- Last few GCs --->
[00:30:46] 1: node::Abort() [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46]
[00:30:46] 2: 0x8c21ec [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46][9362:0x279d280]   660266 ms: Mark-sweep 1395.3 (1457.4) -> 1395.3 (1457.4) MB, 734.4 / 0.0 ms  allocation failure GC in old space requested
[00:30:46][9362:0x279d280]   661003 ms: Mark-sweep 1395.3 (1457.4) -> 1395.2 (1426.4) MB, 737.2 / 0.0 ms  last resort GC in old space requested
[00:30:46][9362:0x279d280]   661778 ms: Mark-sweep 1395.2 (1426.4) -> 1395.2 (1426.4) MB, 775.3 / 0.0 ms  last resort GC in old space requested
[00:30:46]
[00:30:46]
[00:30:46]<--- JS stacktrace --->
[00:30:46]
[00:30:46]==== JS stack trace =========================================
[00:30:46]
[00:30:46]Security context: 0x319797fa5879 <JSObject>
[00:30:46]    1: toString [buffer.js:611] [bytecode=0x78c44dd7af1 offset=31](this=0x18395389ed71 <Uint8Array map = 0x365f93042681>,encoding=0x2464141022d1 <undefined>,start=0x2464141022d1 <undefined>,end=0x2464141022d1 <undefined>)
[00:30:46]    2: arguments adaptor frame: 0->3
[00:30:46]    5: builtin exit frame: parse(this=0x319797f890a9 <Object map = 0x365f93002ba1>,0x319797fb4bc1 <String[4]: utf8>,0x18395389ed71 <Uint8Ar...
[00:30:46]
[00:30:46] 3: v8::Utils::ReportOOMFailure(char const*, bool) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46] 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46] 5: v8::internal::Factory::NewRawOneByteString(int, v8::internal::PretenureFlag) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46] 6: v8::internal::Factory::NewStringFromOneByte(v8::internal::Vector<unsigned char const>, v8::internal::PretenureFlag) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46] 7: v8::internal::Factory::NewStringFromUtf8(v8::internal::Vector<char const>, v8::internal::PretenureFlag) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46] 8: v8::String::NewFromUtf8(v8::Isolate*, char const*, v8::NewStringType, int) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46] 9: node::StringBytes::Encode(v8::Isolate*, char const*, unsigned long, node::encoding, v8::Local<v8::Value>*) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46]10: 0x8e2526 [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46]11: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46]12: 0xad710c [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46]13: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/binary/nodejs/linux64/node]
[00:30:46]14: 0x1183217042fd
[00:30:46]/home/dev/workspace/BUILDS/65196/Bryntum/siesta/bin/puppeteer: line 17:  9362 Aborted                 (core dumped) "$DIR/binary/nodejs/$NODE_BIN_PATH/node" "$DIR/puppeteer-launcher.js" "$DIR" "NOT_USED" "$@"
[00:30:46]Exit code: 134
[00:30:46]Exit code: 134
[00:30:46]After run tests hook

My guess is that memory usage concurrency has changed. Previously, in nyc 13.3, all reports were merged one by one:

NYC.prototype.getCoverageMapFromAllCoverageFiles = function (baseDirectory) {
  var _this = this
  var map = libCoverage.createCoverageMap({})

  this.eachReport(undefined, (report) => {
    map.merge(report)
  }, baseDirectory)
  // depending on whether source-code is pre-instrumented
  // or instrumented using a JIT plugin like @babel/require
  // you may opt to exclude files after applying
  // source-map remapping logic.
  if (this.config.excludeAfterRemap) {
    map.filter(function (filename) {
      return _this.exclude.shouldInstrument(filename)
    })
  }
  map.data = this.sourceMaps.remapCoverage(map.data)
  return map
}

Now, in 15, all data is first fetched into the memory, and then merged:

  async getCoverageMapFromAllCoverageFiles (baseDirectory) {
    const map = libCoverage.createCoverageMap({})

    const data = await this.coverageData(baseDirectory)
    data.forEach(report => {
      map.merge(report)
    })

    map.data = await this.sourceMaps.remapCoverage(map.data)

    // depending on whether source-code is pre-instrumented
    // or instrumented using a JIT plugin like @babel/require
    // you may opt to exclude files after applying
    // source-map remapping logic.
    if (this.config.excludeAfterRemap) {
      map.filter(filename => this.exclude.shouldInstrument(filename))
    }

    return map
  }

There's a max concurrency limit (the pMap) but for some reason it is applied to loading data only. It should be applied both to loading and merging.

…ing in memory (istanbuljs#1263)

canonic-epicure · 2020-03-23T10:33:43Z

PR: #1293

The PR is confirmed to fix the crash in our test suite.

coreyfarrell · 2020-03-23T12:58:41Z

Could those having this issue test using #1293? The requested changes I made will not change the results of your testing so your test against the currently proposed changes should resolve your issue.

canonic-epicure · 2020-03-31T14:48:38Z

@coreyfarrell It seems this issue is not actual anymore for other participants of this thread. The PR do fix the OOM crash in our setup however, verified that. Any idea when/if it will be merged and released as a new version of nyc?

I could move forward with the patch-package of course, but I'd prefer to just bump the nyc dependency.

Fixes #1263

canonic-epicure · 2020-04-02T08:13:04Z

Thanks!

coreyfarrell · 2020-04-02T13:19:16Z

nyc 15.0.1 is now published to npm on the next tag. You can explicitly update to get this fix immediately. The updated version also includes a tweak to the text report so I will promote to latest once I get some feedback on that.

canonic-epicure · 2020-04-02T18:21:28Z

Thank you, I'll update right away.

monsam · 2020-08-13T22:22:44Z

I have 15.1.0 still I am getting the error
WEBPACK Compiled successfully in 10351ms

MOCHA Testing...

<--- Last few GCs --->

[97116:0x110008000] 82254 ms: Mark-sweep 2023.2 (2079.4) -> 2012.6 (2082.4) MB, 3773.9 / 0.0 ms (average mu = 0.082, current mu = 0.040) allocation failure scavenge might not succeed
[97116:0x110008000] 84763 ms: Mark-sweep 2017.0 (2082.4) -> 2013.4 (2084.7) MB, 2494.7 / 0.0 ms (average mu = 0.052, current mu = 0.006) allocation failure GC in old space requested

<--- JS stacktrace --->

==== JS stack trace =========================================

0: ExitFrame [pc: 0x1009311f9]
1: StubFrame [pc: 0x10092d57f]

Security context: 0x3a5b2fb408a1
2: set [0x3a5b2fb4e3d1](this=0x3a5b6c083e21 ,0x3a5baef3da61 ,0x3a5baef3eb49 <JSArray[0]>)
3: node [0x3a5b9dc78f31] [/Users/xx/code/connect/node_modules/@babel/traverse/lib/index.js:~75] [pc=0xc9bff3e7303](this=0x3a5bd8390ad1 <JSFunction traverse (sfi = 0x3a5bdbc76b11)>,0x3a5b...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0x10007f231 node::Abort() [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
2: 0x10007f3b5 node::OnFatalError(char const*, char const*) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
3: 0x100176887 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
4: 0x100176823 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
5: 0x1002fa9d5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
6: 0x1002fc0a4 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
7: 0x1002f8f77 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
8: 0x1002f6f5d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
9: 0x1003026a0 v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
10: 0x1003026ef v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
11: 0x1002ce0c9 v8::internal::Factory::NewFixedArrayWithFiller(v8::internal::RootIndex, int, v8::internal::Object, v8::internal::AllocationType) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
12: 0x1004db1ea v8::internal::HashTable<v8::internal::EphemeronHashTable, v8::internal::EphemeronHashTableShape>::EnsureCapacity(v8::internal::Isolate*, v8::internal::Handlev8::internal::EphemeronHashTable, int, v8::internal::AllocationType) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
13: 0x1004dbe16 v8::internal::ObjectHashTableBase<v8::internal::EphemeronHashTable, v8::internal::EphemeronHashTableShape>::Put(v8::internal::Isolate*, v8::internal::Handlev8::internal::EphemeronHashTable, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, int) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
14: 0x1004fedcd v8::internal::JSWeakCollection::Set(v8::internal::Handlev8::internal::JSWeakCollection, v8::internal::Handlev8::internal::Object, v8::internal::Handlev8::internal::Object, int) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
15: 0x1005e054d v8::internal::Runtime_WeakCollectionSet(int, unsigned long*, v8::internal::Isolate*) [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
16: 0x1009311f9 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/xx/.nvm/versions/node/v12.14.1/bin/node]
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

=============================== Coverage summary ===============================
Statements : Unknown% ( 0/0 )
Branches : Unknown% ( 0/0 )
Functions : Unknown% ( 0/0 )
Lines : Unknown% ( 0/0 )

error Command failed with exit code 1.

mccraveiro · 2020-12-12T15:00:43Z

I'm still facing this on v15.1.0 while using AVA and Typescript

sidverma32 · 2021-04-02T06:41:17Z

{
   "scripts":{
      "server":"node --max-old-space-size={size-value} server/index.js"
   }
}

check this answer: https://stackoverflow.com/questions/38558989/node-js-heap-out-of-memory/66914674#66914674

matiaschileno · 2021-05-24T07:29:23Z

I'm having the same issue on v15.1.0 with mocha

…erge (#131734) * [QA][Code Coverage] fixup for auto config handling pr ## Summary Embed buildkite pipeline definition. Follow up pr to change cc per auto config handling. Also, resolves #132706 Increase worker count for `node scripts/build_kibana_platform_plugins` to 4 workers. Normalize file names within coverage files such that nyc correctly builds the combined summaries. _Ci runs this on myriad servers, so the paths are different, which "breaks" nyc's output_ Split the final merge of functional coverage into 2 passes due to [nyc issue](istanbuljs/nyc#1263) Co-authored-by: kibanamachine <[email protected]>

leonheess · 2022-09-03T00:29:38Z

Delete your coverage output folder and try again.

ilyas5 · 2022-10-03T10:03:27Z

This works for me
Javascript Heap out of Memory
Change the hmr property in package.json
abp-zero-template 10.0.0 (aspnetzero 10.0.0 angular)

"hmr": "node --max_old_space_size=8048 ./node_modules/@angular/cli/bin/ng serve --host 0.0.0.0 --port 4200 --hmr"

It seems like C8 is suffering from the same memory issue NYC used to suffer from Related tickets: bcoe/c8#338 istanbuljs/nyc#1263

Since, nyc 15.0+ is unstable... istanbuljs/nyc#1263

coreyfarrell added the needs more information label Jan 2, 2020

canonic-epicure added a commit to canonic-epicure/nyc that referenced this issue Mar 23, 2020

fix: Merge reports with concurrency limit instead of fetching everyth…

9c95e2d

…ing in memory (istanbuljs#1263)

canonic-epicure mentioned this issue Mar 23, 2020

Data merge concurrency #1293

Merged

coreyfarrell closed this as completed in #1293 Apr 1, 2020

coreyfarrell pushed a commit that referenced this issue Apr 1, 2020

fix: Data merge concurrency limit to prevent OOM (#1293)

df34c1c

Fixes #1263

pabo99 mentioned this issue Nov 11, 2020

Agregando componente de Editar grupo omegaup/omegaup#4818

Merged

4 tasks

dependabot bot mentioned this issue Mar 12, 2021

Bump nyc from 14.1.1 to 15.1.0 sthamizhselvan/postManCollection#8

Open

canonic-epicure mentioned this issue Dec 22, 2021

Potential OOM error bcoe/c8#338

Closed

wayneseymour mentioned this issue May 17, 2022

[QA][Code Coverage] follow up pr for ftr auto config handling & fix merge elastic/kibana#131734

Merged

jan-molak added a commit to serenity-js/serenity-js that referenced this issue May 2, 2023

ci(github): increase memory available to C8

4b016f3

It seems like C8 is suffering from the same memory issue NYC used to suffer from Related tickets: bcoe/c8#338 istanbuljs/nyc#1263

jan-molak added a commit to serenity-js/serenity-js that referenced this issue May 5, 2023

ci(github): increase memory available to C8

b541d0b

It seems like C8 is suffering from the same memory issue NYC used to suffer from Related tickets: bcoe/c8#338 istanbuljs/nyc#1263

tokuhirom added a commit to tokuhirom/line-bot-sdk-nodejs that referenced this issue Nov 2, 2023

Do not run nyc on npm test task.

2b4cf84

Since, nyc 15.0+ is unstable... istanbuljs/nyc#1263

tokuhirom mentioned this issue Nov 2, 2023

Do not run nyc on npm test task. line/line-bot-sdk-nodejs#570

Merged

tokuhirom added a commit to line/line-bot-sdk-nodejs that referenced this issue Nov 2, 2023

Do not run nyc on npm test task. (#570)

07f8b68

Since, nyc 15.0+ is unstable... istanbuljs/nyc#1263

AriPerkkio mentioned this issue Nov 11, 2023

Coverage providers are prone to out-of-memory errors vitest-dev/vitest#4476

Closed

6 tasks

github-actions bot mentioned this issue Apr 19, 2024

chore(main): release nyc 17.0.0 #1558

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

JavaScript heap out of memory in v15.0.0. #1263

JavaScript heap out of memory in v15.0.0. #1263

josephzidell commented Jan 2, 2020

coreyfarrell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

coreyfarrell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

coreyfarrell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

coreyfarrell commented Jan 3, 2020

josephzidell commented Jan 3, 2020

coreyfarrell commented Jan 3, 2020

josephzidell commented Jan 3, 2020

coreyfarrell commented Jan 3, 2020

josephzidell commented Jan 3, 2020

erossignon commented Jan 11, 2020 •

edited by coreyfarrell

Loading

coreyfarrell commented Jan 11, 2020

erossignon commented Jan 11, 2020 •

edited

Loading

erossignon commented Jan 11, 2020

canonic-epicure commented Mar 23, 2020

canonic-epicure commented Mar 23, 2020 •

edited

Loading

coreyfarrell commented Mar 23, 2020

canonic-epicure commented Mar 31, 2020

canonic-epicure commented Apr 2, 2020

coreyfarrell commented Apr 2, 2020

canonic-epicure commented Apr 2, 2020

monsam commented Aug 13, 2020

mccraveiro commented Dec 12, 2020

sidverma32 commented Apr 2, 2021 •

edited

Loading

matiaschileno commented May 24, 2021

leonheess commented Sep 3, 2022

ilyas5 commented Oct 3, 2022 •

edited

Loading

JavaScript heap out of memory in v15.0.0. #1263

JavaScript heap out of memory in v15.0.0. #1263

Comments

josephzidell commented Jan 2, 2020

Link to bug demonstration repository

Expected Behavior

Observed Behavior

Troubleshooting steps

Environment Information

coreyfarrell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

coreyfarrell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

coreyfarrell commented Jan 2, 2020

josephzidell commented Jan 2, 2020

coreyfarrell commented Jan 3, 2020

josephzidell commented Jan 3, 2020

coreyfarrell commented Jan 3, 2020

josephzidell commented Jan 3, 2020

coreyfarrell commented Jan 3, 2020

josephzidell commented Jan 3, 2020

erossignon commented Jan 11, 2020 • edited by coreyfarrell Loading

coreyfarrell commented Jan 11, 2020

erossignon commented Jan 11, 2020 • edited Loading

erossignon commented Jan 11, 2020

canonic-epicure commented Mar 23, 2020

canonic-epicure commented Mar 23, 2020 • edited Loading

coreyfarrell commented Mar 23, 2020

canonic-epicure commented Mar 31, 2020

canonic-epicure commented Apr 2, 2020

coreyfarrell commented Apr 2, 2020

canonic-epicure commented Apr 2, 2020

monsam commented Aug 13, 2020

=============================== Coverage summary =============================== Statements : Unknown% ( 0/0 ) Branches : Unknown% ( 0/0 ) Functions : Unknown% ( 0/0 ) Lines : Unknown% ( 0/0 )

mccraveiro commented Dec 12, 2020

sidverma32 commented Apr 2, 2021 • edited Loading

matiaschileno commented May 24, 2021

leonheess commented Sep 3, 2022

ilyas5 commented Oct 3, 2022 • edited Loading

erossignon commented Jan 11, 2020 •

edited by coreyfarrell

Loading

erossignon commented Jan 11, 2020 •

edited

Loading

canonic-epicure commented Mar 23, 2020 •

edited

Loading

=============================== Coverage summary ===============================
Statements : Unknown% ( 0/0 )
Branches : Unknown% ( 0/0 )
Functions : Unknown% ( 0/0 )
Lines : Unknown% ( 0/0 )

sidverma32 commented Apr 2, 2021 •

edited

Loading

ilyas5 commented Oct 3, 2022 •

edited

Loading