[Meteor 1.4] How to debug building meteor app?

#1

I’m trying to fix

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

Source code available in Github

That throws me meteor build that i need for github-to-heroku see on TravisCI is the same (first build fail, one of latest build, or others from history) also with flags NODE_OPTIONS='--max_old_space_size=2048' see build but no luck.

$ meteor build --architecture=os.linux.x86_64 --directory $HOME/app --server=http://localhost:3000
Linking /
<— Last few GCs —>

554828 ms: Mark-sweep 1371.5 (1456.7) -> 1372.3 (1456.7) MB, 1318.0 / 0 ms [allocation failure] [GC in old space requested].
556181 ms: Mark-sweep 1372.3 (1456.7) -> 1372.3 (1456.7) MB, 1353.5 / 0 ms [allocation failure] [GC in old space requested]. 557516 ms: Mark-sweep 1372.3 (1456.7) -> 1372.3 (1456.7) MB, 1334.7 / 0 ms [last resort gc].
558860 ms: Mark-sweep 1372.3 (1456.7) -> 1372.2 (1456.7) MB, 1343.8 / 0 ms [last resort gc].

<— JS stacktrace —>

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

Security context: 0x380c072b4629
1: registerScope(aka registerScope) [/home/travis/.meteor/packages/meteor-tool/.1.4.0-1.13j49n2++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/escope/lib/scope.js:~124] [pc=0x1ca7b93c537b] (this=0x380c072041b9 ,scopeManager=0x244af2747bc1 < a ScopeManager with map 0x32342b9b37b9>,scope=0x216a6604fa09 < a BlockScope with map 0xc1aa2c73441>)
…

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

#2

I’m running into this issue as well, although it’s very odd we push the same build to multiple Heroku instances and one of them builds fine, while the other fails with this FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory error.

Did you ever find the cause and/or a fix for this issue?

#3

bump, also looking for a solution to this

#4

Do you have any large files in your source tree? And has it ever failed on a computer with a lot of memory? You might also want to check if there are any other memory intense applications running.

#5

i’m getting the same problem when running it on both bitbucket pipelines (4 Gb RAM) AND aws code build (15 Gb RAM). This is for testing. Runs fine on my 2.5 Gb RAM development server

#6

used 1.4.1.1 and it worked fine, apparently it doesn’t work for 1.4.2… there’s an issue for this so hopefully they’re working on it?

#7

I (finally) managed to resolve this under meteor 1.4.3.1.

Background:

The issue is that meteor calls node to build. When it runs, node allocates a certain amount of memory for the V8 engine it runs on. In bigger projects, the default memory allocated for V8 is not sufficient to keep track of everything - it tried to garbage-collect as it gets closer to the limit, but eventually runs out of space and crashes with the error shown.

If we were just running node directly, we could run it with the --max-old-space-size option, which would allow us to set the maximum memory for the V8 engine. The issue is that meteor calls node in its own context and with its own options, so we can’t just add the flag directly to our meteor call.

Solution:
It appears that meteor 1.4.3.1 (and maybe others) will pass along flags and options specified in the TOOL_NODE_FLAGS environment variable when it calls node (others have mentioned NODE_OPTIONS, but it isn’t working for my version of meteor - the flags just get dropped)

So if you want to increase the max memory of the node engine to 4 GB, add an environmental variable TOOL_NODE_FLAGS="–max-old-space-size=4096" to the context you are running meteor in - the option should be passed through to the node call.

(If you don’t know where to set environment variables - it is usually going to be in your IDE build configuration or build script. If you want to sanity check if the option is actually being read, try changing it to gibberish - it should cause meteor to throw an error)

#8

I believe the NODE_OPTIONS environment variable passes flags to the node process which actually runs your code. Meteor has 2 node processes, the “parent” which builds your code, manages hot code reloads, and so on, and then the “child” process which executes the code built by the “parent”.

TOOL_NODE_FLAGS passes options to the parent while NODE_OPTIONS passes options to the child.

#9

That’s great context, it explains why TOOL_NODE_FLAGS fixes the OOM build issue, but why NODE_OPTIONS might be working for other OOM issues. Thanks so much for the explanation!