jest: JavaScript heap out of memory after upgrade to Jest 26

I had the same problem (also while collecting coverage data, on GitHub Actions/CI) and fixed it by limiting the number of workers:

• maxWorkers: 2 in jest.config.js
• or --w 2 as a command line parameter.

Trying to migrate from 26.6.3 to 27.2.5 and got the same issue.

After doing some research, it seems this memory leak has been an ongoing issue since 2019 (Jest 22) so wanted to consolidate some notes here for posterity. Past issues have been related to graceful-fs and I think some have solved it via a hack/workaround that removes graceful-fs and then re-adds graceful-js after running jest. One troubleshooting thread was looking at compileFunction in the vm package as a potential cause. It seems that jest, webpack-dev-server, babel, and create-react-app are using graceful-js as a dependency. The memory leak issue was supposed to be fixed in a newer release of Jest but there may have been a regression since it is popping up again. I can confirm everything was working fine until a substantial amount of Jest tests were created in our environment and then the heap overflows on our CI machine after the heap size grows larger than the allocated memory due to the leak. I’ve tried using 1 worker, runInBand, etc. without success.

The common cause of the issues I’ve seen is collecting coverage via collecting coverage and graceful-fs. I haven’t done an in-depth analysis of those issues but seeing that they are both filesystem-related and having solved my own issue which was related to file imports I suspect they are some version of the same issue I was having.

Wanted to provide the solution I found so others may reap benefits:

The cause:

Using imports of the format import * from 'whatever'

The solution:

Using the format import { whatINeed } from 'whatever' instead dramatically reduced the memory accumulation

i was running into this issue and it appears that upgrading to jest 27 fixed it

@pedrohamarques

I’m facing the same problem. Did you solve it?

Yes, by migrating to mocha + chai + sinon 😃

Updating my jest.config.ts with coverageProvider: 'v8' and maxWorkers: 2 did the trick for me!

I was facing the same error on GitHub actions. I was able to pin down the problem in my case to the currently experimental ESM support #9430.

For comparison here are two profiling screenshots (I followed this article for instructions):

CJS (leaked ~20mb)

ESM (leaked ~1gb 😱 )

I had a similar problem where I used to run into Out of Memory error when Jest started to do coverage on “untested files”. Using v8 as coverage provider solved the issue for me. However, its an experimental feature (as per documentation) - https://jestjs.io/blog/2020/01/21/jest-25#v8-code-coverage

I suspect that this issue might be related to the way that the objects that are being compared are being printed. Filed an issue with a minimal reproduction here: https://github.com/facebook/jest/issues/12364

In effect, Jest will stop short if it’s trying to print a very deeply nested object, but doesn’t account for “total nodes” so for objects that are fairly shallow but very wide (such as many React/Enzyme elements) it will try to print the whole object and will run out of memory while constructing the string.

I had what I thought may be a similar error.

Using --coverage while running inside a container like the node:alpine docker image was a problem for me. I really didn’t need to be running tests in a container so maybe my comment/solution here https://github.com/facebook/jest/issues/5837#issuecomment-1002239562 may help someone.

I had the same problem (also while collecting coverage data, on GitHub Actions/CI) and fixed it by limiting the number of workers:

• maxWorkers: 2 in jest.config.js
• or --w 2 as a command line parameter.

This solved my issue: https://stackoverflow.com/a/68307839/9331978

I was having a similar issue where random tests would timeout. I added three arguments to my jest.config.js file and it seems to have helped. Seems to have been happening on both windows, mac, and in our gitlab pipeline.

testTimeout: 10000, maxConcurrency: 3, maxWorkers: ‘50%’,

Surprisingly the tests execute faster as well. By ~15-20%.

We see this regularly on our tests – the first one succeeds then the second fails.

+1 @alexfromapex solution did not worked for me.

Jest 26.6.3 Node 14.15.4

Dump: https://pastebin.com/Mfwi2iiA

It happens after some re-runs on any CI server (my runners are docker containers). Always after a fresh boot it works normally, and after some runs, it breaks again, only comming back after a new reboot. I tried with 1GB RAM and 2GB RAM machines, same result. It seems not happening with 8GB+ RAM hardware (my local machine).

Some other info I’ve gathered, it happens always after ~5m running, everytime the test log has the same size (it might be happening at same spot).

Not sure if it is related. But I get heap leak for simple expect:

  let items = tree.root.findAllByProps({ testID: 'CrewItem.Employee' })

  expect(items).toHaveLength(8) // stacked and throws leak in 30-60 seconds
  expect(items.length).toEqual(8) // works ok

Clearing cache doesn’t help

We will need a repro that can be downloaded and analyzed. Also, please make sure to clear cache just in case, e.g with jest --clear-cache

For me this happened only on CI. Turns out it was because on CI the default is runInBand, so adding this locally helped me replicate the issue on a local machine. For me it happened when an exception was thrown inside the callback given to a useLayoutEffect(). It just ran for ever, consuming more and more memory. Hope this helps someone in this thread 🙏

Have no idea why this worked for me but I had accidentally removed 'js' from moduleFileExtensions in my jest.config.ts and then that’s when my heap issues started going wild. But when I added it back, my heap issues went away.

So now I have moduleFileExtensions: ['js', 'ts']. Hopefully this helps someone!

We see this regularly on our tests at https://github.com/renovatebot/renovate

I tried a few different solutions that didn’t work for me:

• increasing --max-old-space-size
• using the node flag: node --no-compilation-cache
• use --runInBand
• use --expose-gc
• limiting the number of workers

What did work for me:

Limiting the idle memory per worker using the flag workerIdleMemoryLimit

I’m also limiting the number of workers so maybe it was a combination of the solutions.

I also had this issue, and I had to change my collectCoverageFrom array.

Before I had:

"collectCoverageFrom": [ "**/*.{js,jsx}", "!**/node_modules/**", ... ] But for some reason it seemed to still be running over the node_modules folder. I changed this by taking away the exclude node_modules and changing my patterns to include just the directories I needed:

"collectCoverageFrom": [ "<rootDir>/*.js", "<rootDir>/components/**", I don’t like having to do this, because it may be easy to miss future coverage, but all attempts to exclude the node_modules folder either had other errors or reintroduced the “out of memory” issue.

I have very similar issue,

My test:

const first = [ div_obj, p_obj, a_obj ]; // array with three DOM elements
const second = [ div_obj, p_obj, a_obj ]; // array with same DOM elements
second.push( pre_obj ); // add new obj

expect(first).toEqual(second); // compare two arrays one 3 elements other 4 elements

test should fail within 250 ms (timeout), but it takes 40 sec and it spits out message:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
...
<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x55e78ec781b9]
Security context: 0x086b49dc08d1 <JSObject>
    1: toString [0x2cb560879521](this=0x1a95f0796eb1 <Object map = 0x2b3cdd5e4839>)
    2: printComplexValue(aka printComplexValue) [0x329610605059] [/home/joe/../node_modules/pretty-format/build/index.js:~198] [pc=0x1413a8b0e5ac](this=0x059db4cc04b1 <undefined>,0x1a95f0796eb1 <Object map = 0x2b3cdd5...

Somehow I believe stack trace points to printComplexValue. I also tried toMatchObject, but exactly the same.

Jest: v26.6.3

Oh --clear-cache fixed it.

Same problem in Node 16.20.2 and Jest 29.7.0

What did not work for me:

• Clearing cache
• Limiting maxWorkers to 2 or to 1, or runInBand
• Setting workerIdleMemoryLimit to 1 GB, to 50%, or to 0.2
• Changing Node version is not an option.

This worked:

• Setting NODE_OPTIONS max_old_space_size before running jest:

export NODE_OPTIONS=--max_old_space_size=8192
jest

or

NODE_OPTIONS='--max_old_space_size=8192' jest

I ran into the issue with Node 16.19.0 and Jest 29.7.0.

What did not work for me:

• Clearing cache
• Limiting maxWorkers to 2 or to 1, or runInBand
• Not currently able to upgrade Node or downgrade it to 16.10.0 (as per https://github.com/jestjs/jest/issues/11956)

What did work for me:

• Setting workerIdleMemoryLimit to 1 GB

I tried in on pure Windows and Mac and it’s basically the same behaviour. The single test, which virtually does nothing, takes up about 2.5 GB of RAM. For some reasons that’s too much for my WSL, in PS and Mac the max heap seems to be higher for some reason. With --max-old-space-size=4096 everything is “fine”, it just take 2.5 GB of RAM. But ofc, that’s an absurd amount.
In Windows, jest launches as many workers as I have virtual cores (I think), but each one takes up at least 500 MB, even though there’s nothing to do for them (I run 1 test).

Maybe related: https://github.com/jestjs/jest/issues/11956

My stripped-down sample only seems to use aroud 350MB:

[130094:0x71dd830] 3764 ms: Scavenge 389.2 (415.0) -> 381.8 (418.8) MB, 3.80 / 0.00 ms (average mu = 0.973, current mu = 0.975) task;

It does the same thing, there’s just less code not being executed.

Specifying NODE_OPTIONS=“–max-old-space-size=2048” helped us to solve the issue

I can prevent this error by using fake timers:

jest.test.setup.js:

jest.useFakeTimers();

i have the same issue

Same issue here as well. (using ts-jest)