Skip to content
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

'Allocation failed - JavaScript heap out of memory' error when precompiling ReactJS #188

Open
house92 opened this issue Feb 8, 2017 · 5 comments

Comments

@house92
Copy link

house92 commented Feb 8, 2017

I think I may have a similar problem to #177. When I try to run rake assets:precompile for my production environment, I get the following error:

rake aborted!
ExecJS::RuntimeError:
<--- Last few GCs --->

29309 ms: Mark-sweep 1388.0 (1435.7) -> 1388.0 (1435.7) MB, 912.5 / 0.0 ms [allocation failure] [GC in old space requested].
30317 ms: Mark-sweep 1388.0 (1435.7) -> 1388.0 (1435.7) MB, 1008.7 / 0.0 ms [allocation failure] [GC in old space requested].
31420 ms: Mark-sweep 1388.0 (1435.7) -> 1389.1 (1417.7) MB, 1102.8 / 0.0 ms [last resort gc].
32375 ms: Mark-sweep 1389.1 (1417.7) -> 1390.2 (1417.7) MB, 955.1 / 0.0 ms [last resort gc].

<--- JS stacktrace --->

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

Security context: 0x19d845dcfb51
1: expr_list(aka expr_list) [/private/var/folders/sw/jywkjws13_5dgt0vxkpk4by80000gn/T/execjs20170208-85094-1uc4gyajs:~3623] [pc=0x1833a9f95e4f] (this=0x19d845d04381 ,closing=0xa49cbce7ad1 <String[1]: )>,allow_trailing_comma=0x19d845d04381 ,allow_empty=0x19d845d04381 )
2: arguments adaptor frame: 1->3
3: subscripts(aka subscripts) [/private/var/folder...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/usr/local/bin/node]
2: node::FatalException(v8::Isolate*, v8::Localv8::Value, v8::Localv8::Message) [/usr/local/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/usr/local/bin/node]
4: v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/usr/local/bin/node]
5: v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/usr/local/bin/node]
6: 0x1833a9d079a7
7: 0x1833a9f95e4f
(execjs):1

I've tried adding 'config.browserify_rails.use_browserifyinc = false' to production.rb as recommended in the issue I linked to, but it doesn't seem change anything. I'm using ReactJS for my views, and when I removed about 2/3 of my component files it was able to precompile, but it runs into problems when I try to precompile everything.

And suggestions welcome! Kind of pulling my hair out here 👍🏻

@kooropatfa
Copy link

Any success with this error @house92?

@jkeam
Copy link

jkeam commented Apr 26, 2018

I'm getting this as well. Any success @house92 or @kooropatfa ?

@Scong
Copy link

Scong commented May 23, 2018

For some reason this was happening to us as well when we were using sprockets with react-rails and browserify rails, and we used .jsx extensions with import statements. (browserify being run with bablefication and some other translations). This wasn't happening with .js.jsx extensions...

In general we are trying to move away from the sprocket handoffs with these post processors and have all js modules come in through browserify / eventually webpacker land, as that seems to be where many of the browserify-rails issues are coming from, and seems like a place where things will probably go wrong.

@Scong
Copy link

Scong commented May 23, 2018

Hmm maybe our project is right at the brink of having too many jsx files being processed by browserify-rails, and I was understanding things incorrectly last night. Or maybe any file that is being processed by both browserify-rails and react-rails will cause issues during uglification?

@Scong
Copy link

Scong commented May 24, 2018

We ended up having to stub files in sprockets that would be processed by browserify-rails and then import them in a browserify index files that we added to our sprockets pipeline (so that we would only have one file to be processed by browserify-rails). That seemed to fix the issue, and get us transitioning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants