Jest: Memory leak when using `--coverage`

[philipp-spiess]

Do you want to request a _feature_ or report a _bug_?

This is a bug report.

What is the current behavior?

I was able to isolate an example where adding the --coverage operation will cause a memory leak whereas the absence works just fine.

More specifically, the issue occurs when using a very large JavaScript file (in our case, it's the asm.js artifact of PSPDFKit for Web. To work with JavaScript files of that size without issues, we have to add the file to the transformIgnorePatterns configuration option. As soon as we do this, the test passes as expected.

This was working fine in v22.2.2 and for the non---coverage option, this still works fine.

However, when using the --coverage option, this test started to leak memory when we updated from v22.2.2 to v22.3.0. Hence I assume the exact time this started to cause issues is somewhere in this diff.

If the current behavior is a bug, please provide the steps to reproduce and
either a repl.it demo through https://repl.it/languages/jest or a minimal
repository on GitHub that we can yarn install and yarn test.

I set up a repo that reproduces this behavior here.

What is the expected behavior?

yarn jest

and

yarn jest --coverage

Finishes in a reasonable time without causing the heap to explode.

Please provide your exact Jest configuration

https://github.com/PSPDFKit-labs/jest-leak/blob/master/package.json

Run npx envinfo --preset jest in your project directory and paste the
results here

  System:
    OS: macOS High Sierra 10.13.1
    CPU: x64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
  Binaries:
    Node: 9.7.1
    Yarn: 1.3.2
    npm: 5.6.0
  npmPackages:
    jest:
      wanted: ^22.4.2
      installed: 22.4.2

However, I was also able to reproduce this on other machines (e.g. our CI servers).

I also tried different versions of node without seeing a difference in this behavior.

Please let me know if I can provide further details for you.

[philipp-spiess]

I just found out about coveragePathIgnorePatterns and adding this will make the example pass. I still have no idea why this worked before though.

[jy95]

Thanks @philipp-spiess for this issue : I also have a memory leak with my TypeScript repo : https://github.com/jy95/mediaScan/blob/master/jest.config.js

Even if I used the compiled version of the lib and without the flag collectCoverage , the tests took a lot of times (I evaluated to 3X-4X the regular time in v22.2.0).

As far that I know, v22.2.0 introduced a bug inside the coverage but was fixed in 22.4.X , maybe related ?

  System:
    OS: Windows 10
    CPU: x64 Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
  Binaries:
    Node: 8.9.3
    Yarn: Not Found
    npm: 5.6.0
  npmPackages:
    jest:
      wanted: ^22.4.2
      installed: 22.4.2

[mnquintana]

Just ran into this issue too, and it's sadly preventing us from using Jest for code coverage at all 😢 (the coveragePathIgnorePatterns workaround didn't work for us – we were already using it and still getting the memory leak) – is there any info I could provide that'd help the maintainers with debugging?

[SimenB]

@philipp-spiess We use babel to set up code coverage (babel-plugin-istanbul), which is why it runs even though you use transformIgnorePatterns, and the reason you need coveragePathIgnorePatterns.

@mnquintana a reproduction would be nice 🙂

[JaSpr]

We have coveragePathIgnorePatterns and we're still getting massive memory usage when --coverage is on.

Like for us, without --coverage each thread ends up (max) at about 500MB memory usage over the course of our 2652 tests. WITH --coverage they sometimes crash some threads because they hit the default max_old_space_size (seems to be around 1550GB when they crash)

Increasing the max_old_space_size did resolve the crashes, but we don't want to be doing that on CI.

[SimenB]

Is this a leak, or just high memory usage when collecting coverage?

You can use v8 code coverage if you want, that uses _way_ less memory: https://jestjs.io/docs/en/configuration#coverageprovider-string