docusaurus: [v2] yarn build crashes out of memory after 92% for huge files
π Bug Report
V2: yarn build crashes after 92%
Have you read the Contributing Guidelines on issues?
yes
To Reproduce
Execute yarn build on some nontrivial amount of docs (e.g. 400 md files)
Expected behavior
yarn build does not crash and produces docs
Actual Behavior
This is an outcome of the failing command
Compiling
β Client βββββββββββββββββββββββββ after chunk asset optimization (93%)
β Server βββββββββββββββββββββββββ building (70%) 799/799 modules 0 active
<--- Last few GCs --->
[72094:0x1026a0000] 186455 ms: Mark-sweep 2030.6 (2050.9) -> 2030.4 (2051.4) MB, 1099.8 / 0.0 ms (average mu = 0.150, current mu = 0.157) allocation failure GC in old space requested
[72094:0x1026a0000] 188396 ms: Mark-sweep 2031.1 (2051.4) -> 2030.9 (2051.9) MB, 1725.5 / 0.0 ms (average mu = 0.128, current mu = 0.111) allocation failure GC in old space requested
<--- JS stacktrace --->
==== JS stack trace =========================================
0: ExitFrame [pc: 0x100ea9f02]
Security context: 0x17c4d139a2f1 <JSObject>
1: /* anonymous */(aka /* anonymous */) [0x17c4618e27a9] [/<some location>/Projects/magic-script-typings/website/node_modules/webpack/lib/Stats.js:~568] [pc=0x2ec40ce06684](this=0x17c4754804d1 <undefined>,0x17c4086cc5c1 <ModuleReason map = 0x17c461a50d69>)
2: map [0x17c4d138c321](this=0x17c4b88c7f01 <JSArray[156333]>,0x17c4618e27a9 <JSFunction (sfi = 0...
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
Writing Node.js report to file: report.20190913.100136.72094.0.001.json
Node.js report completed
1: 0x100075bd5 node::Abort() [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
2: 0x100076316 node::errors::TryCatchScope::~TryCatchScope() [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
3: 0x1001697d7 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
4: 0x10016976c v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
5: 0x1005480d5 v8::internal::Heap::FatalProcessOutOfMemory(char const*) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
6: 0x1005491c3 v8::internal::Heap::CheckIneffectiveMarkCompact(unsigned long, double) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
7: 0x100546bc3 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
8: 0x10054487f v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
9: 0x10054f365 v8::internal::Heap::AllocateRawWithLightRetry(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
10: 0x10054f3df v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
11: 0x10051e10f v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationSpace) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
12: 0x1007cf111 v8::internal::Runtime_AllocateInTargetSpace(int, unsigned long*, v8::internal::Isolate*) [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
13: 0x100ea9f02 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/<some location>/.nvm/versions/node/v12.4.0/bin/node]
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 21 (9 by maintainers)
I have a feel it might be related to a famous β92% chunk asset optimizationβ issue described e.g. here: https://github.com/angular/angular-cli/issues/5775
@leoz sure thing. Actually had to send two PRs to fix this issue (cos its dependency problem). We can do better to even reduce the RAM usage, but that will require us to fork another webpack plugin weβre depending on.
btw your amount of docs is very huge. π’ One of the doc is as big as 50kb x.x
thanks, investigate