I've searched and searched, trying to figure this one out, but I'm stumped, along with everyone on my team.
I went through the extremely simple instructions to install ndb globally on a mac mojave setup - simple npm install -g ndb. All went without a hitch, so I went to run a js file through it. Example ndb . or ndb test/mytest.js. The ndb window opens up just fine, but it is completely blank. There's no indication that it is attached to the given file/location, and it isn't actually running the file (which has debugger statements, so I would expect it to stop).
Here's an example of what I see when I run ndb . in my project's root directory:
I've tried installing this locally to the project, reinstalling globally, trying different ndb flags and commands, all producing the same general result. It appears that opening this window always finds the NPM Scripts just fine, but running those, or a file doesn't seem to do anything.
If I keep the window open for awhile, eventually this happens in the console - I'm not sure if it is related or not.
<--- Last few GCs --->
[9414:0x103000000] 277347 ms: Mark-sweep 1412.9 (1506.0) -> 1412.9 (1476.5) MB, 1311.4 / 0.2 ms (+ 0.0 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 1311 ms) last resort GC in old space requested
[9414:0x103000000] 278661 ms: Mark-sweep 1412.9 (1476.5) -> 1412.9 (1476.5) MB, 1313.5 / 0.3 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x5fc058a5ee1 <JSObject>
1: onParseComplete [internal/url.js:~199] [pc=0x1300474ba0a8](this=0x5fcd08dc0d9 <URL map = 0x5fcfb52b811>,flags=1424,protocol=0x5fcd08dc131 <String[5]: file:>,username=0x5fc43102311 <undefined>,password=0x5fc43102311 <undefined>,host=0x5fc43102471 <String[0]: >,port=0x5fc43102201 <null>,path=0x5fcd08dc151 <JSArray[8]>,query=0x5fc43102201 <null>,fragment=0x5fcbb8364c1 <String[68]: /index.js/i...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [/Users/stuart/.nvm/versions/node/v8.9.4/bin/node]
2: node::FatalException(v8::Isolate*, v8::Local<v8::Value>, v8::Local<v8::Message>) [/Users/stuart/.nvm/versions/node/v8.9.4/bin/node]
3: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [/Users/stuart/.nvm/versions/node/v8.9.4/bin/node]
4: v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/Users/stuart/.nvm/versions/node/v8.9.4/bin/node]
5: v8::internal::Runtime_AllocateInTargetSpace(int, v8::internal::Object**, v8::internal::Isolate*) [/Users/stuart/.nvm/versions/node/v8.9.4/bin/node]
6: 0x13004730463d
Any help or ideas on how to fix this would be much appreciated!
It might have something to do with your node version. I had the same problem with node v10.7.0. After an upgrade to v11.6.0 it started working again.
Related
I set a max size to 512mb but it doesn't seem to cause any error and it exceeds the limit and goes up 1.3GB. I understand that node will try to GC when it approaches the limit and error out when it exceeds the set limit. I'm running tests and I want it to not exceed 512mb limit.
OS: Ubuntu 20.04.2 LTS
NODE VERSION : 10.19.0
node --max-old-space-size=512 Server.js
I just need to know if that's a normal behavior
No, it's not.
It makes the flag pointless.
With a simple demo program, the flag works as expected:
$ cat demo.js
let big = [];
while (true) {
big.push(new Array(10000));
}
$ node --version
v16.3.0
$ node --max-old-space-size=512 demo.js
<--- Last few GCs --->
[20343:0x563cd38c25a0] 1112 ms: Mark-sweep 477.8 (523.7) -> 477.5 (525.7) MB, 158.4 / 0.0 ms (average mu = 0.124, current mu = 0.011) allocation failure scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0x563ccf1a6680 node::Abort() [node]
2: 0x563ccf0b28e9 node::FatalError(char const*, char const*) [node]
3: 0x563ccf332082 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
...
Note that Node's command-line flag parsing is order-dependent. E.g. if you run node demo.js --max-old-space-size=512, then the flag won't apply to the execution of demo.js.
If that doesn't answer your question, then please state more clearly what you measured. For example, if you looked at the overall memory usage of the process, that would be expected to be larger than 512MB, because the "old space" is just part of what's in the process -- it's the part that's most controllable. Depending on what your app does, there can be other consumers of memory. While I would find an extra 800MB surprising, anything's possible as long as you don't provide a repro, or more details on what you measured and how.
<--- Last few GCs --->
[972:000001913A837320] 40900 ms: Mark-sweep 2049.2 (2066.3) -> 2047.3 (2059.3) MB, 2062.9 / 0.1 ms (+ 179.6 ms in 113 steps since start of marking, biggest step 8.9 ms, walltime since start of marking 2512 ms) (average mu = 0.153, current mu = 0.107) [972:000001913A837320] 42835 ms: Mark-sweep 2048.8 (2059.3) -> 2047.7 (2057.8) MB, 1845.1 / 0.0
ms (+ 81.8 ms in 23 steps since start of marking, biggest step 9.0 ms, walltime since start of marking 1935 ms) (average mu = 0.084, current mu = 0.004) al
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 00007FF68A20B3BD]
Security context: 0x002c4c9808d1 <JSObject>
1: _append [000002A11D9F9439] [D:\ReactProjects\plotlytest\myplotlysite\node_modules\#babel\generator\lib\buffer.js:~99] [pc=0000014BCF9DB744](this=0x03160f6401b1 <Buffer map = 000000A495510339>,0x02ab7a1c78c9 <String[#1]: >,151182,27,0x02ab7a1c01b9 <null>,0x02ab7a1c04b1 <undefined>,0x02ab7a1c06e9 <false>)
2: append [000002A11D9F9391] [D:\ReactPro...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF6895F5EBF napi_wrap+114095
2: 00007FF6895A0B46 v8::base::CPU::has_sse+66998
3: 00007FF6895A1946 v8::base::CPU::has_sse+70582
4: 00007FF689DB6E4E v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF689D9EF21 v8::SharedArrayBuffer::Externalize+833
6: 00007FF689C6B18C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436
7: 00007FF689C763C0 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
8: 00007FF689C72EE4 v8::internal::Heap::PageFlagsAreConsistent+3204
9: 00007FF689C686E3 v8::internal::Heap::CollectGarbage+1283
10: 00007FF689C66D54 v8::internal::Heap::AddRetainedMap+2452
11: 00007FF689C8809D v8::internal::Factory::NewFillerObject+61
12: 00007FF6899EE06F v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1295
13: 00007FF68A20B3BD v8::internal::SetupIsolateDelegate::SetupHeap+546637
14: 0000014BCF9DB744
npm ERR! code ELIFECYCLE
npm ERR! errno 134
npm ERR! myplotlysite#0.1.0 start: `react-scripts start`
npm ERR! Exit status 134
npm ERR!
npm ERR! Failed at the myplotlysite#0.1.0 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
Above is the error I am recieving. I followed a pretty standard set-up, identical to the one listed on this site: https://github.com/plotly/react-plotly.js/blob/master/README.md
I created a react app. When I create a react app and "npm start" the local host it works perfectly fine. This error occurs when I do the next step:
"npm install react-plotly.js plotly.js" after I do this, the local host no longer works and I get this error.
How can I fix this?
By the way, I'm curious, why does this error still exist for so many years? Is plotly not well for react or something?
There are a couple issues reported regarding this exact problem on the repo issues tracking, like:
JavaScript heap out of memory error with the quickstart Plot example.
Javascript runs out of memory when making production build
In these issues, we clearly see this is a problem with NodeJS <= 10 memory allocation issue and there are several solutions to this:
Try to upgrade your NodeJS version to latest 12.x version
Node >= 12 increases the heap sizes automatically and it will work. I suggesst you install Node Version Manager (nvm) for Windows which will allow you quickly and easily install and switch through multiple node version.
Manually increase max_old_space_size to React scripts
Increase heap size using max_old_space_size by adding this option with a memory size into the package.json script:
"scripts": {
...
"start": "react-scripts --max_old_space_size=4096 start",
"build": "react-scripts --max_old_space_size=4096 build",
...
}
Use Partial bundles
Partial bundles
Starting in v1.15.0, plotly.js also ships with several partial bundles:
basic
cartesian
geo
...
Starting in v1.39.0, each plotly.js partial bundle has a corresponding npm package with no dependencies.
Starting in v1.50.0, the minified version of each partial bundle is also published to npm in a separate "dist min" package.
plotly.js basic
The basic partial bundle contains trace modules scatter, bar and pie.
You can load the library from plotly.js-basic-dist which it's compiled and will consume less memory when bundling:
import React from "react";
// import Plot from "react-plotly.js";
import Plotly from "plotly.js-basic-dist";
import createPlotlyComponent from "react-plotly.js/factory";
const Plot = createPlotlyComponent(Plotly);
When trying to build an Angular project on a Linux server with -aot flag, I get an error. I tried upgrading my instance to a higher CPU core, more RAM and turn on a SWAP partition but still the error just occur faster.
Here's while trying to build from terminal along with the command with the flags I use.
ng build --target=production --environment=prod --aot
Your global Angular CLI version (1.7.2) is greater than your local
version (1.4.7). The local Angular CLI version is used.
To disable this warning use "ng set --global warnings.versionMismatch=false".
10% building modules 5/5 modules 0 activeTemplate parse warnings:
The <template> element is deprecated. Use <ng-template> instead ("
[WARNING ->]<template [ngIf]="!isClosed">
<div [class]="'alert alert-' + type" role="alert" [ngClass]="classes""): ng:///****************node_modules/ngx-bootstrap/alert/alert.component.d.ts.AlertComponent.html#1:0
92% chunk asset optimization
<--- Last few GCs --->
133611 ms: Mark-sweep 1302.6 (1435.2) -> 1297.8 (1435.2) MB, 1112.6 / 0.0 ms [allocation failure] [GC in old space requested].
134724 ms: Mark-sweep 1297.8 (1435.2) -> 1297.7 (1435.2) MB, 1112.7 / 0.0 ms [allocation failure] [GC in old space requested].
135854 ms: Mark-sweep 1297.7 (1435.2) -> 1302.7 (1406.2) MB, 1129.8 / 0.0 ms [last resort gc].
136983 ms: Mark-sweep 1302.7 (1406.2) -> 1307.9 (1406.2) MB, 1128.8 / 0.0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0xb8bacacfb39 <JS Object>
1: find_variable [0xb8baca04381 <undefined>:~3539] [pc=0xbdb4151ee32] (this=0xa9144042161 <an AST_Function with map 0xd6ccb950f99>,name=0x1f852792bb29 <String[12]: DOMException>)
2: visit [0xb8baca04381 <undefined>:3449] [pc=0xbdb4151d969] (this=0x3da6d780b621 <a TreeWalker with map 0xd6ccb9394c9>,node=0x2f9919fb8e91 <an AST_SymbolRef with map 0xd6ccb9628c9>,descend=0x2e68ca83edd1 <JS Fu...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::Abort() [ng]
2: 0x109bf8c [ng]
3: v8::Utils::ReportApiFailure(char const*, char const*) [ng]
4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [ng]
5: v8::internal::Factory::NewInternalizedStringImpl(v8::internal::Handle<v8::internal::String>, int, unsigned int) [ng]
6: v8::internal::StringTable::LookupString(v8::internal::Isolate*, v8::internal::Handle<v8::internal::String>) [ng]
7: v8::internal::LookupIterator::PropertyOrElement(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, bool*, v8::internal::LookupIterator::Configuration) [ng]
8: v8::internal::Runtime::GetObjectProperty(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>) [ng]
9: 0xed3501 [ng]
10: v8::internal::Runtime_KeyedGetProperty(int, v8::internal::Object**, v8::internal::Isolate*) [ng]
11: 0xbdb262092a7
Aborted (core dumped)
I tried the solution mentioned here, https://www.npmjs.com/package/increase-memory-limit
But still with no luck
For prod build, run following command:
node --max_old_space_size=4096 node_modules/#angular/cli/bin/ng build
--target production
For more optimization flags, below command:
It has inbuilt cache busting and other goodies:
node --max_old_space_size=4096 node_modules/#angular/cli/bin/ng build
--target production --build-optimizer --vendor-chunk
try running
node --max-old-space-size=8192
where 8192 is size in MB
As Filipe Silva recommends in the angular-cli repository, add a new entry in the scripts section of your package.json file:
"ng-high-memory": "node --max_old_space_size=8000 ./node_modules/#angular/cli/bin/ng",
and use it this way:
npm run ng-high-memory --
You have to remember to use the double dash before the arguments, otherwise they might not be parsed correctly:
npm run ng-high-memory -- serve
This does not look like a hardware limitation problem as such which can be resolved by upgrading the memory or processor.
I once had a build running out of memory, but it turned out that there was a circular reference where a source file A required a source file B and then B also required A. It was a code design issue, of course.
I would suggest you to try a simple build first and check to see if it goes well.
ng build
Also, the Angular doc mentions that when using ng build --prod, (not --target=production), it performs an AOT compilation, among other things:
https://angular.io/guide/deployment
The --prod meta-flag engages the following optimization features.
Ahead-of-Time (AOT) Compilation: pre-compiles Angular component templates.
Production mode: deploys the production environment which enables production mode.
You might want to install the latest version of the Angular CLI and see if that helps.
I faced same issue on Angular 4 project. The problem is my Node Js version is not compatible Angular 4, I installed Node Js v6.17.1 and problem resolved for me.
For more details Angular and Node Js compatibility you can visit this link : Is there a compatibility list for Angular / Angular-CLI and Node.js?
I faced with the same problem. as a solution adding Swap file worked for me.
Sometimes occur this error.
<--- Last few GCs --->
[2856:00000253F09D3B90] 11688472 ms: Mark-sweep 1529.8 (1619.4) -> 1529.7 (1583.4) MB, 1835.6 / 0.0 ms last resort GC in old space requested
[2856:00000253F09D3B90] 11690272 ms: Mark-sweep 1529.7 (1583.4) -> 1529.7 (1579.4) MB, 1799.7 / 0.0 ms last resort GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 000001F6C9E25739 <JSObject>
1: completeMany [C:\Users\mobasher.fasihy\Documents\GitHub\jobsaf-server\node_modules\mongoose\lib\query.js:~1459] [pc=0000006F3C3482B8](this=0000029E4B604F01 <JSGlobal Object>,model=00000090CCBE6729 <JSFunction model (sfi = 000001A244DDB931)>,docs=0000025B74FA8591
<JSArray[53714]>,fields=0000025B74FA8FF1 <Object map = 00000207F58823B9>,userProvidedFields=0000025B74FA9029 <Object map = 000...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: node::DecodeWrite
2: node_module_register
3: v8::internal::FatalProcessOutOfMemory
4: v8::internal::FatalProcessOutOfMemory
5: v8::internal::Factory::NewUninitializedFixedArray
6: v8::internal::WasmDebugInfo::SetupForTesting
7: v8::internal::interpreter::BytecodeArrayRandomIterator::UpdateOffsetFromIndex
8: 0000006F3C2043C1
[nodemon] app crashed - waiting for file changes before starting...
Randomly above error occur on the server, and app crashes.
While you can use David's workaround, I d advise to search for the root cause.
There is not a lot of probable cause for Out Of Memory errors:
A recursive call got so long it broke the stack trace
You created a extremely heavy object
You got a lot of data at once
If the root cause is a recursive call, which was a common mistake when node.js was chock full of callback, there was one line that gave the control back to the event loop so it could clear up after itself (process.nextTick or something similar)
For the two other cause, which nowadays are the most likely culprit, especially when using a DB, you will need to either use streams, so that you never get the full data at once in memory, or find another way to divide the work.
Which process is throwing the error?
Try setting the max_old_space_size setting (in MB)
node --max_old_space_size=4096 <yourScriptHere>
I'm trying to build my meteor app and am constantly running into the below error. This is not the first time I'm building the app and everything worked fine until yesterday's build. I already tried: as suggested in one of the answeres in [this SO post][1] but it did not help.
#!/usr/bin/env node --max_old_space_size=4096 --optimize_for_size --max_executable_size=4096 --stack_size=4096
Console output:
meteor build .
WARNING: The output directory is under your source tree.
Your generated files may get interpreted as source code!
Consider building into a different directory instead
meteor build ../output
Minifying app code \
<--- Last few GCs --->
103230 ms: Mark-sweep 1385.5 (1455.5) -> 1387.9 (1455.5) MB, 898.4 / 0 ms [allocation failure] [GC in old space requested].
104206 ms: Mark-sweep 1387.9 (1455.5) -> 1387.9 (1455.5) MB, 975.8 / 0 ms [allocation failure] [GC in old space requested].
105196 ms: Mark-sweep 1387.9 (1455.5) -> 1384.1 (1455.5) MB, 990.2 / 0 ms [last resort gc].
106101 ms: Mark-sweep 1384.1 (1455.5) -> 1385.1 (1455.5) MB, 905.3 / 0 ms [last resort gc].
<--- JS stacktrace --->
==== JS stack trace =========================================
Security context: 0x249f6fdb4629 <JS Object>
1: /* anonymous */(aka /* anonymous */) [0x249f6fd041b9 <undefined>:~4943] [pc=0xcd10dd2f48c] (this=0x249f6fd041b9 <undefined>,self=0x1400b413881 <an AST_ObjectKeyVal with map 0xc3d3a4651b9>,output=0x17417c4edd79 <an Object with map 0x16588927e021>)
2: doit(aka doit) [0x249f6fd041b9 <undefined>:4190] [pc=0xcd10d7a3298] (this=0x249f6fd041b9 <undefined>)
3: print [0x249f6fd041b9 <unde...
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory
Aborted (core dumped)
This same issue was driving me nuts, but I finally managed to resolve it 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 --max-old... option is actually being read, try changing it to gibberish - it should cause meteor to throw an error)
You need to take notice of that initial warning:
WARNING: The output directory is under your source tree.
Your generated files may get interpreted as source code!
Consider building into a different directory instead
meteor build ../output
Read what it says - basically it will be producing files, and then compiling them in as well. No wonder it gets into trouble and runs out of memory. Put the build in a different directory (not within the Meteor project) and it should be a lot happier :)