-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Javascript Heap out of memory when Karma serving files #2673
Comments
I have seen this as well, but when using the watcher and Chrome. It was not consistently reproducible for me though (Node 6.9.4). Could this be related to karma-webpack? My team uses karma-webpack, but we don't use the webpackMiddleware option. |
The webpack middleware settings just turn on some reporting. I am almost positive this has to do with karma as running webpack-dev-server with similar settings does not result in the same crash in node. It seems to me the karma has a memory leak somewhere. When analyzing the memory usage for karma, I did notice that out of about 1 .4 GB of heap space used, almost 1 GB was being used to store strings. It seems like most of the strings are not actually being referenced by a file Karma is serving, and I am sure that some of them are needed, the larger ones just seem to extraneous copies of other strings. I am not the greatest as debugging memory issues but It seems like only one of these should exist at a time since the are the same file. The other issue I am seeing is the string size being stored is much larger than the actual size of the file. In the screenshot attached, the file is emitted by webpack. Together with its source map, it is 9.79 MB but karma is using about 50 MB to store the string representation of the file, which seems to indicate that it is somehow adding extra data to the strings. |
I tracked down the core issue to a webpack loader (jsx-loader) some how causing a memory leak. However I think there are optimization that can be made to karma to reducing its memory usage, as in the above post, having to different file object constructed for the same file seems like a waste. |
@CTaylor1118 thanks for your investigation 👍 About files from the picture, This is strange that files don't have a path/originalPath. Maybe this files was created by webpack-plugin |
@maksimr Sorry about that, they actually have a complete filepath to a real, I just commented it out for work purposes. |
Has anyone figured out any ways to mitigate this issue? |
I'm having the same issue (without using |
I tried narrowing down this on my PC. It only occurs with node x86. 100% reproducable with version 6.13.1. I will try to take a snapshot but I think my machine is too weak for this leak (woooord ;) ) |
Who is meant to clean up following a test run (with |
How could a socket.io connection accumulate so much memory unless you constantly open new connections which shouldn't be possible? |
I have this PR #2981 but I think this issue is different as you all seem to be using one instance of Karma while I spawn many. |
Hi guys. |
I'm unsure if this is related, but we recently began preprocessing our karma sources to move inline sourcemaps into .map files before bundling and serving. This dropped the number of bytes shipped to the browser and allowed tests that failed on memory to pass. |
We fixed this issue by following what's suggested at: https://github.com/webpack-contrib/karma-webpack#alternative-usage A config like:
leads to webpack bundling the whole app for EACH .test.js file. The alternative-usage will bundle the app only once -> in our cases, instaed of having dozens of 20MB files (i.e. strings maintained in memory), we ended with a single 50MB file. |
Expected behaviour
Single run tests runs consistently and watch mode can recompile consistently
Actual behaviour
Node crashes because of the heap running out of memory when just serving a few dozen files.
Environment Details
OS: Mac OS Sierra 10.12.4
Node: 6.9.5
"karma": "^1.6.0",
"karma-chai": "^0.1.0",
"karma-chrome-launcher": "^2.0.0",
"karma-cli": "^1.0.1",
"karma-mocha": "^1.3.0",
"karma-mocha-reporter": "^2.2.3",
"karma-phantomjs-launcher": "^1.0.4",
"karma-sinon-chai": "git://github.com/kmees/karma-sinon-chai#bca7e7a2d6e90d4c7c6a6884550c2b3228596d23",
"karma-sourcemap-loader": "^0.3.7",
"karma-webpack": "^2.0.3",
"mocha": "^3.2.0",
"webpack": "^1.12.14",
"webpack-dev-server": "^1.14.1"
karma --version
): 1.6.0karma.config.js
filekarma.config.js
Steps to reproduce the behaviour
This does not happen consistently in single run mode but virtually every time when watching. The problem presents itself after the compilation is complete and karma is serving the files. Happens in bother Phantomjs and Chrome. Judging from the stack trace provided by node, it seems like a buffer on a stream may be getting too large. The heap getting to about 1.259 GB for just a few dozen files. I have seen the same issue with using webpack 2+; I downgraded to see if that would resolve the issue and it did not. The problematic code seems to be in the karma middleware.
The text was updated successfully, but these errors were encountered: