nodejs / help

:sparkles: Need help with Node.js? File an Issue here. :rocket:
1.48k stars 284 forks source link

Fatal JavaScript invalid size error 169220804 #3728

Open honk7608 opened 2 years ago

honk7608 commented 2 years ago

Details

#
#Fatal error in , line 0
#Fatal JavaScript invalid size error 169220804
#
#
#
#FailureMessage Object: 0000007BACEF9D60
 1: 00007FF625B0401F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+112511
 2: 00007FF625A2116F v8::CFunctionInfo::HasOptions+7055
 3: 00007FF6266F7302 V8_Fatal+162
 4: 00007FF626280C65 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArray+101
 5: 00007FF62612A463 v8::internal::FeedbackNexus::ic_state+62771
 6: 00007FF626140FC0 v8::Message::GetIsolate+15840
 7: 00007FF625FB5681 v8::internal::CompilationCache::IsEnabledScriptAndEval+26849
 8: 00007FF6264534B1 v8::internal::SetupIsolateDelegate::SetupHeap+494417
 9: 000001872985A558 

Why this error happend and how can I fix?

Node.js version

v16.13.2

Example code

No response

Operating system

Window 11

Scope

runtime

Module and version

Not applicable.

luorixiangyang commented 2 years ago

Anyone who can resolve this issue?

VoltrexKeyva commented 2 years ago

According to the stacktrace of the error, it seems like you're trying to initialize an array with way too many elements, this is caused by the V8 engine as there's a maximum array size specified.

The maximum amount of elements can vary depending on the target machine, but the common maximum size is the 32-bit unsigned integer, AKA 4,294,967,296 (4,29 billion) elements, if you try to create an array larger than this, that can be caused, although as said, this is depenedent on the target machine and the maximum heap it could provide as well.

yolpsoftware commented 2 years ago

How can I find out which line of code causes the array that is too big?

Too bad there isn't a stacktrace of the Javascript code that causes it. After all, there is a specific line of code that adds the element that makes the array too big.

In my case, it seems to be a non-terminating loop that adds elements to an array. Of course there are methods to find the cause, but a stacktrace would be quite helpful.

rdtriny commented 2 years ago

I moved "react-scripts": "5.0.1" from dependencies to devDependencies in package.json , this saved me.

linlei2099 commented 2 years ago

I moved "react-scripts": "5.0.1" from dependencies to devDependencies in package.json , this saved me.

It works for me. What is the impact of this config change?

MYLESMUGISHA commented 2 years ago

how did you fix that error in your code? cause am having the same error

occupy5 commented 1 year ago

What framework are you using, For me, I lowered the next.js version and it worked.

zainali-bracketsltd commented 1 year ago

I was having this issue with Nestjs v 9.20 when I tried to install stripe. I moved all of my @types/* dependecies to dev dependencies and now everything works.

TheSecurityDev commented 1 year ago

I'm having this issue with NextJS 12.3 when dev is set to true like const nextServer = next({ dev: true });

Edit: I resolved it by deleting the .next folder.

MaddyGuthridge commented 1 year ago

What I want to know is why this error instantly crashes Node with no backtrace and no meaningful explanation - surely this could just be handled by throwing an exception, which would allow the error to be caught by test runners and presented nicely in CI rather than causing everything to break.

Muhangi2 commented 1 year ago

I moved "react-scripts": "5.0.1" from dependencies to devDependencies in package.json , this saved me.

Aworldc commented 1 year ago

i encountered this error using JSFuck 0.5.0

MridulSheikh commented 1 year ago

I was having this issue with Nestjs v 9.20 when I tried to install stripe. I moved all of my @types/* dependecies to dev dependencies and now everything works.

Thank's its work for me 👍❤️

yanickrochon commented 8 months ago

In my case, it was a cyclical dependency within a monorepo project. Turbo was able to recognise this when I tried to run a custom cleanup job, which removes all .turbo, .next, node_modules, and re-installs everything. It failed with the exact cyclical path.

tom-carbontrail commented 8 months ago

In my case, it was a cyclical dependency within a monorepo project. Turbo was able to recognise this when I tried to run a custom cleanup job, which removes all .turbo, .next, node_modules, and re-installs everything. It failed with the exact cyclical path.

@yanickrochon could you share the contents of your cleanup job? I am facing the same issue in a monorepo project.

yanickrochon commented 8 months ago

@tom-carbontrail sure!

The turborepo's root package.json has this (partial file content):

{
  "private": true,
  "packageManager": "pnpm@8.10.2",
  "scripts": {
    "reset": "turbo reset && rimraf pnpm-lock.yaml node_modules && pnpm i"
  },
  "devDependencies": {
    "rimraf": "^5.0.5"
  }
}

The turbo.json file (partial)

{
  "$schema": "https://turborepo.org/schema.json",
  "pipeline": {
    "reset": {
      "cache": false
    }
  }
}

Each of my package.json look like this (partial, update according to your own build requirements) :

{
  "name": "@vit3x/accounts",
  "scripts": {
    "reset": "rimraf .next .turbo node_modules"
  }
}

Thens imply run pnpm reset. This will flush all artefacts and node_modules, then reinstall everything.

tom-carbontrail commented 8 months ago

Ah I see. My files look similar, I wondered if you were running a script or similar to detect cyclic dependencies.

I added 'import/no-cycle': ["warn"], to my Eslint config to help me find them in my project, and found the culprits. My tests (with jest) now run again.

Thanks for your help.

yanickrochon commented 8 months ago

@tom-carbontrail pnpm warns about cyclical dependencies when you run pnpm i and it has to rebuild the cache. If your solution works, that's great too!

srayo16 commented 6 months ago

I moved "react-scripts": "5.0.1" from dependencies to devDependencies in package.json , this saved me too.

RedYetiDev commented 4 months ago

Hi! If this issue is resolved, could a member (or the author) close it? If it's not resolved, ignore this message.

If you don't have access, and you think this issue is resolved, :+1: this message, and I'll close the issue myself.

Thanks!