Fatal Javascript invalid size error

[georeith]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

yarn start inside of a docusaurus project installed with yarn 3 using the pnpm linkage mode triggers the following error:

#
# Fatal error in , line 0
# Fatal JavaScript invalid size error 169220804
#
#
#
#FailureMessage Object: 0x16fd35ba8
 1: 0x1001d8a70 node::NodePlatform::GetStackTracePrinter()::$_3::__invoke() [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 2: 0x1010ee0b4 V8_Fatal(char const*, ...) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 3: 0x100444c90 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 4: 0x1005d122c v8::internal::(anonymous namespace)::ElementsAccessorBase<v8::internal::(anonymous namespace)::FastPackedObjectElementsAccessor, v8::internal::(anonymous namespace)::ElementsKindTraits<(v8::internal::ElementsKind)2> >::GrowCapacity(v8::internal::Handle<v8::internal::JSObject>, unsigned int) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 5: 0x1007d1294 v8::internal::Runtime_GrowArrayElements(int, unsigned long*, v8::internal::Isolate*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 6: 0x100b2902c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
 7: 0x1061e20b4
 8: 0x105f0a8a0
 9: 0x1065dabec
10: 0x100ab24d0 Builtins_JSEntryTrampoline [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
11: 0x100ab2164 Builtins_JSEntry [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
12: 0x1003f5ce0 v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
13: 0x1003f5214 v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
14: 0x1002e57fc v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
15: 0x1000c4eec node::InternalCallbackScope::Close() [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
16: 0x1000c548c node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
17: 0x1000da310 node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
18: 0x10017b8c8 node::fs::FSReqCallback::Resolve(v8::Local<v8::Value>) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
19: 0x10017c08c node::fs::AfterStat(uv_fs_s*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
20: 0x100a91c18 uv__work_done [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
21: 0x100a953b4 uv__async_io [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
22: 0x100aa712c uv__io_poll [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
23: 0x100a95844 uv_run [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
24: 0x1000c5ccc node::SpinEventLoop(node::Environment*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
25: 0x1001b1cec node::NodeMainInstance::Run(int*, node::Environment*) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
26: 0x1001b19c4 node::NodeMainInstance::Run() [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
27: 0x10014a5d0 node::Start(int, char**) [/Users/george/.nvm/versions/node/v18.3.0/bin/node]
28: 0x10500d0f4

I have also seen this other issue but they were unable to make a reproduction: #8421

Reproducible demo

https://github.com/georeith/docusuraus-issue-fatal-size

I created this reproduction by:

1. Installing yarn 3 and configuring its linkageMode to pnpm
2. Running npx create-docusaurus@latest site classic --typescript -p yarn

(reproducible without TypeScript too)

Steps to reproduce

1. Clone the repo
2. Install yarn 3
3. Run yarn
4. Run yarn start
5. Click around the documentation site, within a minute it should crash and you should see a similar error in the terminal.

Untitled.2.mp4

Expected behavior

The site should not crash

Actual behavior

The site crashes

Your environment

• Public source code: https://github.com/georeith/docusuraus-issue-fatal-size
• Docusaurus version used: 2.3.0
• Environment name and version (e.g. Chrome 89, Node.js 16.4): Node 18.3.0, Yarn 3.3.1,
• Operating system and version (e.g. Ubuntu 20.04.2 LTS): macOS Monterey (m1)

Self-service

• I'd be willing to fix this bug myself.

[Josh-Cena]

So to clarify: you were able to reproduce this issue by just using Yarn v3, without changing any code in the init template?

[Josh-Cena]

First I want to say that the Yarn setup is not recommended: you should install v3 locally in .yarn/releases—the global yarn should always be the v1 one. Apart from that, I can reproduce the error, but I can't tell if it's a Yarn3 + pnpm nodeLinker issue, or really a Docusaurus issue. There doesn't seem to be anything obviously wrong from our side. Some observations:

1. yarn start instantly freezes. There's no way to terminate the process until it crashes.
2. It doesn't reproduce with using pnpm directly, or any other nodeLinker (node-modules or pnp).

[georeith]

First I want to say that the Yarn setup is not recommended: you should install v3 locally in .yarn/releases—the global yarn should always be the v1 one.

I check in a yarn release or use corepack normally, but what's the reasoning behind not using yarn 3 as your default?

1. yarn start instantly freezes. There's no way to terminate the process until it crashes.

This was my experience too except it freezes after webpack compilation completes (you can still cancel during)

[georeith]

Update:

I found this issue: yarnpkg/berry#4525

I tested docusaurus with webpack cache disabled via a plugin like so:

const disableWebpackCachePlugin = () => ({
  name: 'disableWebpackCache',
  configureWebpack() {
    return { cache: false };
  }
})

And it works.

So the issue appears to be with webpack cache and yarn 3's pnpm linker.

It appears a potential fix for this has been merged into Yarn: yarnpkg/berry#4542 but not yet released under an official version.

[georeith]

Can confirm that using yarn set version canary which installed 4.0.0-rc.37 is working correctly.

[Josh-Cena]

Great, glad you found the reason :)

[georeith]

For anyone else who has this problem and finds this issue, you may find yourself stuck between a rock and a hard place because even though Yarn 4 RC has a fix for this issue, if you use turbo or esbuild those will fail to install with the RC as of now: yarnpkg/berry#5165.

Instead I found a workaround (it's not elegant I know) using the following postinstall script (replace site/ with your docusaurus folder in a monorepo or remove it in a standard repo):

{
  "postinstall": "rm -rf site/node_modules/@docusaurus/core/node_modules/terser-webpack-plugin/node_modules/webpack"
}

This removes the circular symlink that gets created each time yarn install runs which caused the initial issue.

To make matters worse, yarn doesn't run postinstall after every install so you may need to use something like: https://github.com/mhassan1/yarn-plugin-after-install to make it work all the time.