yarn serve - JavaScript heap out of memory crash

[xrei]

Version

3.0.0-beta.15

Reproduction link

https://github.com/xrei/vuecli-bug

Steps to reproduce

Well.. it's not hard to reproduce but takes time.
Run yarn serve
and develop for some hours :)

What is expected?

Stable working dev server

What is actually happening?

After some hours (~1-2) dev server will crash with an error:

 95% emitting CopyPlugin
<--- Last few GCs --->

[2032:000001F314F3C8F0]  5471846 ms: Mark-sweep 1381.6 (1414.7) -> 1381.6 (1414.7) MB, 250.8 / 0.0 m
s  allocation failure GC in old space requested
[2032:000001F314F3C8F0]  5472120 ms: Mark-sweep 1381.6 (1414.7) -> 1381.6 (1413.7) MB, 273.5 / 0.0 m
s  last resort GC in old space requested
[2032:000001F314F3C8F0]  5472433 ms: Mark-sweep 1381.6 (1413.7) -> 1381.6 (1413.7) MB, 313.7 / 0.0 m
s  last resort GC in old space requested


<--- JS stacktrace --->

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

    0: ExitFrame [pc: 000001CC26384281]
Security context: 000002F26A1206A9 <JSObject>
    1: fromString(aka fromString) [buffer.js:349] [bytecode=0000006AEF71E081 offset=148](this=000001
3071A022E1 <undefined>,string=0000031511A4D141 <Very long string[3793765]>,encoding=000002F26A131A29
 <String[4]: utf8>)
    2: from [buffer.js:201] [bytecode=0000006AEF71DC01 offset=11](this=0000023CE59638A9 <JSFunction
Buffer (sfi = 0000037B38A8B959)>,val...

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::Heap::MaxHeapGrowingFactor
 6: v8::internal::Factory::NewRawTwoByteString
 7: v8::internal::Smi::SmiPrint
 8: unibrow::Utf8DecoderBase::WriteUtf16Slow
 9: v8::String::WriteUtf8
10: std::basic_ostream<char,std::char_traits<char> >::basic_ostream<char,std::char_traits<char> >
11: node::Buffer::New
12: node::Buffer::New
13: v8::internal::interpreter::BytecodeDecoder::Decode
14: v8::internal::RegExpImpl::Exec
15: v8::internal::RegExpImpl::Exec
16: v8::internal::RegExpImpl::Exec
17: 000001CC26384281
error Command failed with exit code 134.

[ryouaki]

change the scripts at package.json as below
node --max_old_space_size=4096 node_modules/@vue/cli-service/bin/vue-cli-service.js serve --open

[ryouaki]

this is not an issue from vue-cli ,this is the limit from nodejs.

[yyx990803]

There's nothing vue-cli can do about this.

[atinybeardedman]

Just in case anyone else finds this issue I had to change the package.json serve script to the following:

"serve" : "node --max_old_space_size=4096 node_modules/.bin/vue-cli-service serve --open"

@ryouaki your path didn't work for me

[xrei]

"dev": "npx --max_old_space_size=4096 vue-cli-service serve"

@atinybeardedman this worked for me

but just wanna say, that my own webpack config doesn't have this issue with memory
also i'm sure i have enough memory. just strange behaviour.
maybe it's because of webpack 4. I don't know.

[ryouaki]

@xrei this is because of your code. for me , in my project , i have more than 500 pages and more 100 base components , and with a large assets and css with cssmodule.
some bad practice with cssmodule from junior developer , this will take large memory. ( ´▽｀)

[ryouaki]

@atinybeardedman you should change the path to you own path which you saved the vue-cli scripts.

[octref]

@yyx990803 You can fix this by adding --max_old_space_size=4096 to the hashbang of cli-service.

I only had a small project that I developed for 3 hours, and this happened for at least 5 times. I feel a lot of people might run into this issue.

Root cause is here: webpack/webpack#1914 (comment). From what I read in the thread, it seems to be that the memory usage from sourcemap generation & file watching hits V8's limit (1400MB). Bumping the limit to 4GB should make the ceiling much harder to hit.

[yyx990803]

@octref we can do that for now. Although in the long run we probably want to see if there's anything we can do to reduce the heap usage. I think it's because a single Vue file actually involves multiple source maps being passed and merged.

[chokn]

Adding a directory of large library files to my project's .eslintignore file fixed the issue for me.

[vanderlin]

I get this crash after about 10 saves and webpack tries to compile.

[DRoet]

I'm also having this problem a few times / day after a few dozen of saves even when increasing the max_old_space_size=4096. I never had this problem using the old vue cli 2.9.x + webpack template and the default max_old_space_size. perhaps an upstream bug somewhere that is increasing the heap ?

[vanderlin]

I'm still getting this crash as well - have tried the --max_old_space_size=4096 but still crashes after about 10 mins. The old vue-cli webpack worked great no problems at all. Any thoughts, solutions, anything???

[DRoet]

Might be related to: webpack/webpack#6929

[mercer08]

i'm currently used version is 3.0.0-beta.15(often crashed because of memory leaks), what can I do to upgrade to the new version(v3.0.0-rc.3)?

[DRoet]

@vanderlin try updating your dev-dependencies:

rm -rf [package-lock.json] node_modules && npm cache clean -f && npm i

make sure u get webpack: ^4.15.1 and postcss-loader: ^2.1.6 since they fixed some memory leaks in these versions.

I have been seeing a lot less memory usage (no crashes yet) but I'll have to test it out more to tell if it is completely fixed.

[octref]

@DRoet I have been testing webpack 4.15.1 + and postcss-loader 2.1.6+ too, and it seems the memory leak issue is much better. Do you want to send a PR? I'm in China now and for some reason cannot download certain dependencies in vue-cli (chromedriver) and yarn would fail to update the lock file.

You can just update webpack / postcss-loader at /packges/@vue/cli-service.

[DRoet]

@octref I checked and the current dev branch already has webpack: ^4.15.1 and postcss-loader: ^2.1.6

[octref]

Oh...Seems @Akryum unintentionally fixed 3 memory leaks 93940c2#diff-90339eb44e295051bd16d3e099b219d8 😛

[Akryum]

That was intentional, I've been monitoring the issue on webpack repo 😸

[havefive]

edit package.json

"serve":"node --max_old_space_size=4096 node_modules/@vue/cli-service/bin/vue-cli-service.js serve --open"

[ffxsam]

For what it's worth, I haven't had this issue in a very long time, and I didn't change anything about my setup.

[xrei]

That's right. in the latest vue-cli this isn't happening anymore.

[runxc1]

So I see that this issue is closed but none of the fixes noted here in changing the package.json seem to fix the issue. I was using the Vue UI and am no longer able to and am starting to no longer be able to make more than 2 or 3 changes before it runs out of memory.

I am trying increase the memory for the following script

"build-watch": "vue-cli-service build --mode development --dest ../../wwwroot/vue --target app --watch"
and get an error when I attempt to change it to

"build-watch": "node --max_old_space_size=4096 node_modules/.bin/vue-cli-service build --mode development --dest ../../wwwroot/vue --target app --watch"

[leonardotessaroalves]

solution:

npm i -D cross-env

"scripts"; { "dev": "cross-env NODE_OPTIONS=--max_old_space_size=8192 vue-cli-service serve --mode development" }

[jinzunyue]

1. Try to increase the heap size
2. If you don't ignore the /dist in .gitignore, then you need to add /dist into the .eslintignore

thinks,it really helps me.

[anyderre]

If your application crash while building scss files try installing those dependencies node-sass, style-loader and sass-loader, this worked for me!

[chelentos]

solution:

npm i -D cross-env

"scripts"; { "dev": "cross-env NODE_OPTIONS=--max_old_space_size=8192 vue-cli-service serve --mode development" }

for me worked even just cross-env NODE_ENV=development vue-cli-service serve
thank you

[mirzaumersaleem]

add .eslintignore to your project directory will do a workaround sample .eslintignore file

node_modules
.env
.env.development
.env.production
.vscode
coverage
upload
ngrok.exe
.babelrc
build
test
README.md

[billyc]

There is definitely a (large) memory leak causing yarn serve / npm serve to crash consistently and reproducibly. Yes, I can delay that crash somewhat by increasing memory for Node until my dev machine has swapped everything else out of RAM. Not sure why this issue is closed?

This memory leak is most egregious when I use web workers, I think since they bundle several npm libraries, and apparently the entire thing is then leaked. I can crash the yarn serve process on my second build without fail, with my project's particular combination of web workers, typescript, and babel. But I can see that that combo is not required for the memory leak to occur.

Every time a file-save event triggers a build, the node process inches up in memory. (In my case it "inches up" by about 400k RAM on every save). I've bumped Node up to a max of 4GB of RAM which sometimes gets me through a couple hours of dev before it crashes.

I'd like to help find the actual cause. What can I do to help?

• I've experienced this problem with every version of vue-cli since I started using the 3.x release
• With every version of TypeScript from 2.6 up to current 3.6
• Using each of Node 8.x, 10.x, and 12.x. No difference; the memory leak is always there.
• Adding folders to .eslintignore does not solve the problem for me
• This is on WSL Ubuntu 18.04 LTS if that makes any difference.
• My project uses the following vue-cli plugins: babel, eslint, typescript, unit-jest.

Hoping these details help us find a real solution!

[verymuch]

@xrei this is because of your code. for me , in my project , i have more than 500 pages and more 100 base components , and with a large assets and css with cssmodule.
some bad practice with cssmodule from junior developer , this will take large memory. ( ´▽｀)

which kinds of bad practices will lead to this problem? Can you give me some suggestions?

[soletan]

which kinds of bad practices will lead to this problem? Can you give me some suggestions?

It's kind of off-topic, but in server-side Javascript coding it's mostly unreleased event listeners that cause a running software to grow huge over time. When using streams quite frequently it's rather easy to have some recently used event listeners left unreleased. I'd suggest to use unit tests for they can help to find the culprits that prevent a test runner from exiting due to unreleased resources.

Apart from that there are other more obvious causes for wasting memory e.g. when caching stuff in memory without cleaning out from time to time or even the simplest algorithms implemented in a wrong way so e.g. arrays are growing huge...

In context of VueJS it might be related to accidentally saving references, like working with render() functions or using vm.$el to access some DOM element directly for attaching event listeners which has been bad without VueJS before and so it's still bad today. Caching issues are possible there as well.

[kumaresan-subramani]

So I see that this issue is closed but none of the fixes noted here in changing the package.json seem to fix the issue. I was using the Vue UI and am no longer able to and am starting to no longer be able to make more than 2 or 3 changes before it runs out of memory.

I am trying increase the memory for the following script

"build-watch": "vue-cli-service build --mode development --dest ../../wwwroot/vue --target app --watch"
and get an error when I attempt to change it to

"build-watch": "node --max_old_space_size=4096 node_modules/.bin/vue-cli-service build --mode development --dest ../../wwwroot/vue --target app --watch"

@runxc1 , it throws below error:

D:\ej2-vue-samples>npm run check2

> [email protected] check2 D:\ej2-vue-samples
> node --max_old_space_size=4096 node_modules/.bin/vue-cli-service build --mode development

D:\ej2-vue-samples\node_modules\.bin\vue-cli-service:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
          ^^^^^^^

SyntaxError: missing ) after argument list
    at new Script (vm.js:79:7)
    at createScript (vm.js:251:10)
    at Object.runInThisContext (vm.js:303:10)
    at Module._compile (internal/modules/cjs/loader.js:657:28)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)
    at Function.Module.runMain (internal/modules/cjs/loader.js:742:12)
    at startup (internal/bootstrap/node.js:283:19)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] check2: `node --max_old_space_size=4096 node_modules/.bin/vue-cli-service build --mode development`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] check2 script.

i am using like below:

"check":"node --max_old_space_size=4096 node_modules/@vue/cli-service/bin/vue-cli-service.js build --open",

[cristiancpl]

Any solution ?

[aguegu]

Well, not in every case can we enlarge the heap size easily. In my practice, i have apps (docker) built for both amd64, arm32v7. And the arm32v7 version is supposed to built on a Raspberry Pi 3B, which only got 1GB ram. It may take longer, but I will eventually get what I need. But when this error occurs, the whole RPi building toolchain fail to deliver.

[parthibd]

Facing the same problem . I have around 300 components and cannot build . Always out of heap memory.

[gmhafiz]

I have tried --max_old_space_size=4096 but that didn't work for me. What fixed this issue for me is I deleted dist folder

rm -R dist

[snake-py]

I have the same problem, trying to solve it for the whole day already.

The easy fix everyone suggested is not working:

        "serve": "vue-cli-service serve",
        "serve2": "node --max_old_space_size=8192 node_modules/@vue/cli-service/bin/vue-cli-service.js serve",
        "serve3": "node --max_old_space_size=8192 node_modules/@vue/cli-service/bin/vue-cli-service.js serve --open",

[parthibd]

Just disable preetify. It will work.

[snake-py]

Just disable preetify. It will work.

How do I do that ?

[snake-py]

Hey,

So the problem is even after upping the memory I get something like this:

<--- Last few GCs --->

[17688:000001EBFBD96490]    63998 ms: Scavenge 4054.6 (4135.7) -> 4053.0 (4136.5) MB, 11.7 / 0.0 ms  (average mu = 0.660, current mu = 0.625) allocation failure
[17688:000001EBFBD96490]    64016 ms: Scavenge 4055.2 (4136.5) -> 4054.0 (4138.5) MB, 13.5 / 0.0 ms  (average mu = 0.660, current mu = 0.625) allocation failure
[17688:000001EBFBD96490]    65942 ms: Scavenge 4056.8 (4138.5) -> 4055.4 (4146.5) MB, 1922.4 / 0.0 ms  (average mu = 0.660, current mu = 0.625) allocation failure


<--- JS stacktrace --->

FATAL ERROR: MarkCompactCollector: young object promotion failed Allocation failed - JavaScript heap out of memory
 1: 00007FF7DDDB4BFF napi_wrap+159807
 2: 00007FF7DDD48A36 v8::internal::MicrotaskQueue::GetMicrotasksScopeDepth+67174
 3: 00007FF7DDD49936 node::OnFatalError+294
 4: 00007FF7DE64CA3E v8::Isolate::ReportExternalAllocationLimitReached+94
 5: 00007FF7DE63110D v8::SharedArrayBuffer::Externalize+781
 6: 00007FF7DE4CA14C v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
 7: 00007FF7DE4B5068 v8::internal::NativeContextInferrer::Infer+59352
 8: 00007FF7DE499C3F v8::internal::MarkingWorklists::Local::SwitchToContextSlow+60639
 9: 00007FF7DE4ADFE1 v8::internal::NativeContextInferrer::Infer+30545
10: 00007FF7DE4A513D v8::internal::MarkCompactCollector::EnsureSweepingCompleted+6285
11: 00007FF7DE4AD10E v8::internal::NativeContextInferrer::Infer+26750
12: 00007FF7DE4B13CB v8::internal::NativeContextInferrer::Infer+43835
13: 00007FF7DE4BB2B2 v8::internal::ItemParallelJob::Task::RunInternal+18
14: 00007FF7DE4BB241 v8::internal::ItemParallelJob::Run+641
15: 00007FF7DE48D3ED v8::internal::MarkingWorklists::Local::SwitchToContextSlow+9357
16: 00007FF7DE4A56DE v8::internal::MarkCompactCollector::EnsureSweepingCompleted+7726
17: 00007FF7DE4A3E24 v8::internal::MarkCompactCollector::EnsureSweepingCompleted+1396
18: 00007FF7DE4A1528 v8::internal::MarkingWorklists::Local::SwitchToContextSlow+91592
19: 00007FF7DE4CFF91 v8::internal::Heap::LeftTrimFixedArray+945
20: 00007FF7DE4D2175 v8::internal::Heap::PageFlagsAreConsistent+709
21: 00007FF7DE4C7371 v8::internal::Heap::CollectGarbage+1969
22: 00007FF7DE4C5605 v8::internal::Heap::AllocateExternalBackingStore+1493
23: 00007FF7DE4E7690 v8::internal::Factory::NewFillerObject+192
24: 00007FF7DE20D60A v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1386
25: 00007FF7DE6D3D4D v8::internal::SetupIsolateDelegate::SetupHeap+456749
26: 0000003BF6CB5098

What I have tried so far

1. Up memory like this:

"serve": "vue-cli-service serve",
"serve2": "node --max_old_space_size=8192 node_modules/@vue/cli-service/bin/vue-cli-service.js serve",
"serve3": "node --max_old_space_size=8192 node_modules/@vue/cli-service/bin/vue-cli-service.js serve --open",

Results in the same problem, just a little later.

2. I also played around with the vue.config file, but this did not work I tried to up the memor there like it is described here https://stackoverflow.com/a/55810460 This resulted in several other problems, but I think it kinda solved the memory problem only because I did then not load all files, once I set up every loader manually I ran into the same issue

3. since the other dev is using linux and it is working fine for him I thought well if it is windows, then I just use docker. DId result in the same issue.

AT this point I guess it is due to many scss imports because this project consists out of 20+ dashboards that are completely styled independently.

Has someone any suggestion on how I can find the resource devouring process? I guess the original problem for me is that windows allocate memory differently compared to unix systems. I will next try to up swap space on my machine, perhaps this will help. I guess Linux is killing a memory intense process later or not until the swap space is fully exhausted. From what I know by now windows is allocating swap dynamically, and it decides differently whether to kill a process or not - perhaps someone with more knowledge can confirm my guess.

[douglasg14b]

After restarting vue cli, any variant of --max_old_space_size=4096 command still results in the same error:

<--- Last few GCs --->

[91484:03E9DFD0]    53499 ms: Mark-sweep (red
uce) 823.9 (1019.7) -> 818.9 (994.1) MB, 191.7 / 0.1 ms  (average mu = 0.921, current mu = 0.013) last resort GC in old space requested
[91484:03E9DFD0]    53703 ms: Mark-sweep (reduce) 818.9 (982.1) -> 818.2 (962.9) MB, 204.1 / 0.1 ms  (average mu = 0.828, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

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

This issue also presents itself ONLY with the Vue CLI, if I run npm run serve from a terminal, this issue doesn't exist. Which kind of points to this being a potential vue clli issue despite @yyx990803 closing this as a "not our problem".

[sobancodes]

Is this in anyway a cause of concern for the production app? I am concerned because I am using dynamic components with keep-alive. I have 5 components in keep-alive and I am only loading the components asynchronously. 😴

[ChiefTechDev]

"build": "node --max-old-space-size=8192 node_modules/vite/bin/vite.js build",