Node.js "FATAL ERROR: JS Allocation failed - process from memory" - can I get a stack trace?

Question

Good ... I'll be back to square one. I can’t figure it out for the life of me.

I get the following error:

FATAL ERROR: JS Allocation failed - process out of memory 

I could list dozens (yes, dozens) of the things that I was trying to find at the root of this problem, but in reality it would be too much. So, here are the key points:

• I can only get it on my production server, and my application is large and complex, so it is very difficult to isolate
• This happens despite the heap size and RSS size being <200 MB, which should not be a problem considering that the machines (Amazon Cloud, CentOS, m1.large) have 8 GB RAM.

My guess is that (due to the second point) the leak is probably not the cause; rather, it looks like the SINGLE object is very large. The following thread supports this theory :: In Node.js, using JSON.stringify results in a "process out of memory" error

What I really need is to find out what state of memory is at the time of the application crash, or maybe a stack trace leading to FATAL ERROR.

Based on my assumption above, a 10 minute heap heap is insufficient (since the object will not be in memory).

Answer 1

I need to give Trevor Norris a huge props on this, helping to change node.js so that it automatically generates a bunch of dumps when this error occurs.

Ultimately, the solution to this problem was much more mundane for me. I wrote some simple codes that added the endpoint of each incoming API request to the log file. I was waiting to collect ~ 10 data points (failures) and compared the endpoints that were started 60 seconds before the crash. I found that in 9/10 cases the only endpoint that was hit just before the crash.

From there, it was just a matter of deepening into the code. I cut it all - returning less data from my mongoDB requests, passing only the necessary data from the object back to the callback, etc. Now we have switched 6 times more than the average, without a single failure on any of the servers, which led me to hope that it is resolved ... for now.

Answer 2

Just because this is the most correct answer on Google at the moment, I decided that I would add a solution for the case that I just encountered:

I had this problem using express with ejs templates - the problem is that I could not close the ejs block, and the file was js code - something like this:

 var url = '<%=getUrl("/some/url")' /* lots more javascript that ejs tries to parse in memory apparently */ 

This is obviously a super-specific case, the OP solution should be used in most cases. However, the OP solution will not work for this (ejs stack trace will not be displayed using ofe ).

Answer 3

There is no single solution to this problem.
I read various cases, most of which were related to JS, but in my case, for example, it was just a broken jade pattern loop that was infinite due to a code error.

I assume this is just a syntax error that node is not handling well.
Check your code or post it to find the problem.

Answer 4

In my case, I deployed Rails 4.2.1 through cap deployment (capistrano) and during the resulting precompilation:

rake stdout: rake aborted! ExecJS :: RuntimeError: FATAL ERROR: evacuation failure - memory processing (Execjs): 1

I ran a dozen data import using active_admin before, and it looks like it used all RAM

Solution: Server reboot and deployment are performed for the first time ....

Answer 5

Could there be a problem with recursion on the object you are serializing, just for starters, and memory runs out before recursion becomes a problem?

I created a safe-clone-deep npm module for this reason ... basically you want to do the following.

 var clone = require('safe-clone-deep'); ... return JSON.stringify(clone(originalObject)); 

This will allow you to clone almost any object, which will then be serialized safely. In addition, if one of the objects inherits from Error , it will serialize the inherited name , message and stack properties, since they are usually not serialized.

Answer 6

In our case, we accidentally allocated a huge (sparse) array, due to which util.format exploded:

http://grahamrhay.wordpress.com/2014/02/24/fatal-error-js-allocation-failed-process-out-of-memory/

Answer 7

In my case, I initialized an associative array (Object) using []. As soon as I initialized it as {}, the problem disappeared.

Answer 8

In my case, the file that I used to sow db during development caused a leak. For some reason, node did not like the multi-line comment I had at the end of the file. I do not see anything wrong with this, but the exclusion process means that I know this section of this file.

Answer 9

When analyzing a number of cases, the most common problem is the infinite loop problem. This will be difficult to solve in a complex application, that is, where development based on tests is useful!

Answer 10

I spent several days to find the cause of the problem. The "JS - process out of memory" error started to occur when building a web package only in an AWS EC2 instance. The build was successful on my local system.
The reason was the following code:
Previous:
import { ShoppingCartOutlined } from "@material-ui/icons/ShoppingCartOutlined";
This has been fixed:
import ShoppingCartOutlined from "@material-ui/icons/ShoppingCartOutlined";

This may help someone using material-ui / icons and end up with this error.

Answer 11

Sharing what is happening here:

I lost a few days with this problem until I discovered that in some file I was importing a class from one static file, the built file. This causes the build process to never end. Something like:

 import PropTypes from "../static/build/prop-types"; 

Correction to a real source solved the whole problem.

Answer 12

Using npm 5.0.3 on an AWS instance, we had permission problems in the npm global folder itself, which probably caused this to happen to us. we ran: sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share} now it works fine

Answer 13

I have the same problem. I restarted the system using the "sudo reboot" command. Then I tried again. It worked.