Skip to content

vite build error: out of memory #2433

New issue
New issue
Open
Open
vite build error: out of memory#2433
Labels
has workaroundhelp wantedExtra attention is neededp4-importantViolate documented behavior or significantly improves performance (priority)performancePerformance related enhancement
@vijay19920608

Description

@vijay19920608
vijay19920608
opened on Mar 8, 2021 · edited by benmccann

NOTE - PLEASE READ

This issue has affected a number of people. Please do not comment with comments along the lines of "I'm also hitting this", but add a thumbs up to the issue instead. We know this is an important issue and "me too" comments will only drown out the comments from people attempting to resolve this issue and will be hidden. Please note however that Vite is a community driven project and a fix may need to come from the community

For tips on working around the issue, please see https://rollupjs.org/guide/en/#error-javascript-heap-out-of-memory

Describe the bug

vite build error: out of memory.

Reproduction

https://github.com/Axeldeblen/realworld-big-build

Possible improvements

Reduce magic string memory usage when building source maps: Rich-Harris/magic-string#161 (comment)

Logs (Optional if provided reproduction)

<--- JS stacktrace --->

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

0: ExitFrame [pc: 00007FF69790ABBD]
Security context: 0x01e6a86408d1
1: decode(aka decode) [000002AD02F874D1] [E:\vite-template\node_modules_rollup@2.40.0@rollup\dist\shared\rollup.js:~133] [pc=0000039464A55451](this=0x037824a004b1 ,0x017863480119 <Very long string[1502653]>)
2: decodedSourcemap(aka decodedSourcemap) [000002AD02F8A979] [E:\vite-template\node_modules_rollup@2.40.0@rollup\dist\shared\roll...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF696CD180F napi_wrap+119407
2: 00007FF696C787E6 v8::internal::OrderedHashTablev8::internal::OrderedHashSet,1::NextTableOffset+38102
3: 00007FF696C795E6 node::OnFatalError+438
4: 00007FF6974B5A6E v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF69749DC21 v8::SharedArrayBuffer::Externalize+833
6: 00007FF69734F3FC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1436
7: 00007FF69735A640 v8::internal::Heap::ProtectUnprotectedMemoryChunks+1312
8: 00007FF697357154 v8::internal::Heap::PageFlagsAreConsistent+3204
9: 00007FF69734C953 v8::internal::Heap::CollectGarbage+1283
10: 00007FF69734AFC4 v8::internal::Heap::AddRetainedMap+2500
11: 00007FF69736C30D v8::internal::Factory::NewFillerObject+61
12: 00007FF6970CF76F v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=+1295
13: 00007FF69790ABBD v8::internal::SetupIsolateDelegate::SetupHeap+546925
14: 0000039464A55451

Activity

vijay19920608
added
pending triage
on Mar 8, 2021
mutoe
mentioned this on Mar 8, 2021
alexgrozav

alexgrozav commented on Mar 8, 2021

@alexgrozav
alexgrozav
on Mar 8, 2021 · edited by alexgrozav

Update It worked when I allocated a whopping 16GB of RAM for Vite's initialization cycle.

As a temporary workaround, you can use the following commands. If it still fails, just increase the size.

Temporary workaround

a. Using command line arguments

node --max_old_space_size=16384 ./node_modules/vite/bin/vite.js

b. Using environment variables

export NODE_OPTIONS=--max-old-space-size=32768

I'm getting the same error on https://github.com/inkline/inkline/tree/inkline3 after updating from 2.0.0-beta.60 to 2.0.5, but during dev, not build.

It looks like a memory leak to me. I've tried starting from a clean project and gradually added my code to it in order to find the issue. I discovered that it only happens when I rm -r node_modules, npm install and then npm run dev. If I work on the project with Vite already initialised and cached, it won't happen. I know that because I've started from a clean project 5 times. Every time after I move the files over to the old location and go through the installation, it will crash.

I tried increasing the memory allocation size to 9GB, but it didn't do the trick.

> vite


<--- Last few GCs --->

[17331:0x108008000]    46671 ms: Mark-sweep (reduce) 9192.9 (9207.7) -> 9192.9 (9207.7) MB, 8.7 / 0.0 ms  (average mu = 0.232, current mu = 0.001) allocation failure scavenge might not succeed
[17331:0x108008000]    46681 ms: Mark-sweep (reduce) 9192.9 (9204.7) -> 9192.9 (9205.7) MB, 9.4 / 0.0 ms  (average mu = 0.149, current mu = 0.029) last resort GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0x1012e4da5 node::Abort() (.cold.1) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 2: 0x1000a6239 node::Abort() [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 3: 0x1000a639f node::OnFatalError(char const*, char const*) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 4: 0x1001e9007 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 5: 0x1001e8fa3 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 6: 0x100397e95 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 7: 0x10039995a v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 8: 0x100395029 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 9: 0x1003928c1 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
10: 0x1003932d2 v8::internal::Heap::CollectAllAvailableGarbage(v8::internal::GarbageCollectionReason) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
11: 0x1003a121e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
12: 0x10036eb87 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
13: 0x1006ed8d8 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
14: 0x100a7a239 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
15: 0x100accdde Builtins_RegExpSplit [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
zsh: abort      npm run dev

Randomly, I also get this error:

<--- Last few GCs --->

[18228:0x110008000]    43509 ms: Mark-sweep (reduce) 9192.9 (9204.7) -> 9192.9 (9205.7) MB, 8.9 / 0.0 ms  (average mu = 0.154, current mu = 0.039) last resort GC in old space requested
[18228:0x110008000]    43518 ms: Mark-sweep (reduce) 9192.9 (9204.7) -> 9192.9 (9205.7) MB, 9.0 / 0.0 ms  (average mu = 0.087, current mu = 0.001) last resort GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0x1012e4da5 node::Abort() (.cold.1) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 2: 0x1000a6239 node::Abort() [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 3: 0x1000a639f node::OnFatalError(char const*, char const*) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 4: 0x1001e9007 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 5: 0x1001e8fa3 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 6: 0x100397e95 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 7: 0x1003a128c v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 8: 0x10036eb87 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
 9: 0x1006ed8d8 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
10: 0x100a7a239 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
11: 0x100accdde Builtins_RegExpSplit [/Users/alexgrozav/.nvm/versions/node/v14.16.0/bin/node]
zsh: abort      node --max_old_space_size=9192 ./node_modules/vite/bin/vite.js
danranVm

danranVm commented on Mar 9, 2021

@danranVm
danranVm
on Mar 9, 2021 · Hidden as off-topic
fadi-george

fadi-george commented on Mar 15, 2021

@fadi-george
fadi-george
on Mar 15, 2021

For me at least, Vite was compiling my tests coverage folder which led to this heap error so I had to specify root: src in the config. Maybe optimizeDeps could also be set to exclude coverage but I haven't tried it.

patak-dev
added
bug
and removed
pending triage
on Mar 21, 2021
cpati-kochava

cpati-kochava commented on Apr 1, 2021

@cpati-kochava
cpati-kochava
on Apr 1, 2021

I could only get it to work with node 15 on an Apple M1 without having to increase the max_old_space_size value. Either node 12 or 14 would run out of memory.

ghost mentioned this on Apr 14, 2021
Shinigami92
added
p2-edge-caseBug, but has workaround or limited in scope (priority)
on Apr 15, 2021
TheDutchCoder

TheDutchCoder commented on Apr 15, 2021

@TheDutchCoder
TheDutchCoder
on Apr 15, 2021 · edited by TheDutchCoder

It turns out I also had a coverage directory that was the cause of this issue.
I can't seem to set the root to 'src', no matter what I try, unless (I guess) I move the index.html file into src?

Either way, it would be good to have some sort of exclude option in the Vite config for this.

Edit: I wonder if it's due to there being an index.html file in one of those directories and Vite picking that up as if it were an entry point. Might be worth investigating from that angle.

Shinigami92

Shinigami92 commented on Apr 16, 2021

@Shinigami92
Shinigami92
on Apr 16, 2021 · Hidden as off-topic
samuveth

samuveth commented on May 2, 2021

@samuveth
samuveth
on May 2, 2021 · Hidden as off-topic
Shinigami92

Shinigami92 commented on May 2, 2021

@Shinigami92
Shinigami92
on May 2, 2021
Member

@samuveth You should workaround this by using --max-old-space-size=<your-mem -512mb or so> for now

Shinigami92
added
has workaround
on May 2, 2021

201 remaining items

dbkr
mentioned this on Apr 3, 2023
Kodnot

Kodnot commented on Apr 6, 2023

@Kodnot
Kodnot
on Apr 6, 2023

In case it helps someone else, what finally worked for us:

  • Raising the memory limit to 3GB with NODE_OPTIONS=--max-old-space-size=3072
  • Raising the build agent memory limit to 4GB, since it didn't have memory swap enabled it would crash after exceeding 3GB limit with no clear error.

All the other various workarounds listed in the comments didn't resolve the issue.

Something that helped debug the issue was building the project in WSL, I couldn't reproduce the issue when running build locally on windows but could do so when building the project through wsl.

VHQDevFS

VHQDevFS commented on Apr 7, 2023

@VHQDevFS
VHQDevFS
on Apr 7, 2023

Any updates about this bug? I've got this issue too (in GH actions), but none of the methods above worked. This bug unreproducible on local machine, and GH logs don't say something about the reason of the problem.

I got GH actions working by installing cross-env and altering the NPM build script to the following

"build": "cross-env NODE_OPTIONS=--max-old-space-size=8192 vite build",

Thank your solution.

EfstathiadisD

EfstathiadisD commented on Apr 7, 2023

@EfstathiadisD
EfstathiadisD
on Apr 7, 2023 · Hidden as duplicate
danny-avila
mentioned this on Apr 7, 2023
danorlando
mentioned this on Apr 7, 2023
synnovsh
mentioned this on Apr 11, 2023
andokai

andokai commented on Apr 11, 2023

@andokai
andokai
on Apr 11, 2023 · Hidden as spam
EfstathiadisD

EfstathiadisD commented on Apr 11, 2023

@EfstathiadisD
EfstathiadisD
on Apr 11, 2023 · Hidden as off-topic
IanVS

IanVS commented on Apr 11, 2023

@IanVS
IanVS
on Apr 11, 2023 · edited by IanVS
Contributor

@patak-dev I wonder if perhaps this issue should be considered an upstream problem with rollup, and closed here, since there is a lot of noise and I think everything that can be said, has been said. In the end, there's nothing I think Vite can do to solve this issue.

patak-dev

patak-dev commented on Apr 11, 2023

@patak-dev
patak-dev
on Apr 11, 2023
Member

Even if it is upstream, it is an important issue for a lot of folks so it makes sense to keep tracking it here. I'm afraid people will create new issues if we close this one. Let's keep it open but read-only to avoid generating so many notifications to everybody until it is solved in rollup.

vitejs
locked and limited conversation to collaborators on Apr 11, 2023
oneforalone
added a commit that references this issue on Jul 12, 2023

fix: vitejs/vite#2433, build error

a4a88b1
patak-dev
removed
bug
on Feb 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    has workaroundhelp wantedExtra attention is neededp4-importantViolate documented behavior or significantly improves performance (priority)performancePerformance related enhancement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @jwoertink@fc@anthon@tjk@squidsoup

        Issue actions
          vite build error: out of memory · Issue #2433 · vitejs/vite