FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

Do you want to request a feature or report a bug? BUG

What is the current behavior? When bundling for debug, the Metro bundler will crash with: FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory. The project contains a lot of images and JS files

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test. The project can be considered as a large project with with a lot of images and JS files. When using react native 0.56, the bundling would take +/- 20-30 seconds with the same project.

What is the expected behavior? TheMetro bundler should not choke on projects with lots of images

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.

Metro 0.45.3 Node 8.11.3

React Native Environment Info: System: OS: macOS High Sierra 10.13.6 CPU: x64 Intel® Core™ i7-4770HQ CPU @ 2.20GHz Memory: 745.65 MB / 16.00 GB Shell: 3.2.57 - /bin/bash Binaries: Node: 8.11.3 - ~/.nvm/versions/node/v8.11.3/bin/node npm: 5.6.0 - ~/.nvm/versions/node/v8.11.3/bin/npm Watchman: 4.9.0 - /usr/local/bin/watchman SDKs: iOS SDK: Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3 Android SDK: Build Tools: 27.0.3, 28.0.0 API Levels: 23, 25, 26, 27, 28 IDEs: Android Studio: 3.1 AI-173.4819257 Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild npmPackages: react: ^16.5 => 16.5.1 react-native: ^0.57.0 => 0.57.0 npmGlobalPackages: react-native-cli: 2.0.1 react-native-git-upgrade: 0.2.7 react-native-rename: 2.2.2

[tetreault]

I still have this issue. i’m at the very starting point of an AR react native app with Viro media. The metro bundler crashes consistently (but also sometimes is totally fine).

 BUNDLE  [ios, dev] ./index.js ░░░░░░░░░░░░░░░░ 0.0% (0/225)
<--- Last few GCs --->

[66779:0x102801600]    42060 ms: Mark-sweep 874.4 (957.4) -> 874.4 (924.9) MB, 59.6 / 0.0 ms  (average mu = 0.873, current mu = 0.000) last resort GC in old space requested
[66779:0x102801600]    42124 ms: Mark-sweep 874.4 (924.9) -> 874.4 (924.9) MB, 64.0 / 0.0 ms  (average mu = 0.760, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 0x103de94841bd]
Security context: 0x1424f221e589 <JSObject>
    1: _send [0x142469faa4c1] [internal/child_process.js:715] [bytecode=0x1424a1acca91 offset=606](this=0x1424575618b9 <ChildProcess map = 0x1424ac78ade9>,message=0x142431982201 <JSArray[4]>,handle=0x14248af822e1 <undefined>,options=0x142431982289 <Object map = 0x1424ac78bc59>,callback=0x14248af822e1 <undefined>)
    2: send [0x142469faa469] [internal/child_...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: node::Abort() [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 2: node::OnFatalError(char const*, char const*) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 3: v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 4: v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 5: v8::internal::Heap::AllocateRawWithRetry(int, v8::internal::AllocationSpace, v8::internal::AllocationAlignment) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 6: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 7: v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 8: v8::String::Utf8Length() const [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
 9: node::StringBytes::Size(v8::Isolate*, v8::Local<v8::Value>, node::encoding) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
10: int node::StreamBase::WriteString<(node::encoding)1>(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
11: void node::StreamBase::JSMethod<node::LibuvStreamWrap, &(int node::StreamBase::WriteString<(node::encoding)1>(v8::FunctionCallbackInfo<v8::Value> const&))>(v8::FunctionCallbackInfo<v8::Value> const&) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
12: v8::internal::FunctionCallbackArguments::Call(v8::internal::CallHandlerInfo*) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
13: v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
14: v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) [/Users/stephentetreault/.nvm/versions/node/v10.4.0/bin/node]
15: 0x103de94841bd
16: 0x103de9493429
17: 0x103de9493429
18: 0x103de948c223
Abort trap: 6

node: v10.4.0 npm: 6.4.1 react native: 0.55.1 OS: mac OS mojave device: iphone x running iOS 12

[paulmand3l]

I think I figured it out. I tracked the files in dev-mode and noticed that it was getting stuck at 99.2% (file 1502/1508) for a long time. The file that was getting transformed after parser.js was the problem:

{ action_name: 'Transforming file',
  action_phase: 'end',
  file_name: '/Users/username/Code/project/node_modules/aws-sdk/dist/aws-sdk-react-native.js',
  duration_ms: 36722,
  log_entry_label: 'Transforming file' }

Solution here: https://github.com/aws/aws-sdk-js/issues/1877