search

plantain-00 / type-coverage

A CLI tool to check type coverage for typescript code
MIT License
1.26k stars 44 forks source link

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory, when I run type-coverage command on few of the packages! #124

Open spaul1042 opened 1 year ago

spaul1042 commented 1 year ago

Version(if relevant): 1.0.0

Environment(if relevant):

macOS. viscose, node version 16.15.0, nvm version 0.36.0

Code(if relevant):

running the command `type-coverage -p path/to/package`
the command runs fine for all other packages, but for some of the packages, it yields a FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory.

I don't know why it happens, can someone please help me out with this?

Expected:

no error!

Actual:

the entire error is below:

<--- Last few GCs --->

[17744:0x140008000] 79009 ms: Mark-sweep 4041.7 (4138.4) -> 4027.4 (4140.2) MB, 2551.8 / 0.0 ms (average mu = 0.109, current mu = 0.078) allocation failure scavenge might not succeed [17744:0x140008000] 80092 ms: Mark-sweep 4043.9 (4140.7) -> 4029.8 (4142.7) MB, 1039.4 / 0.0 ms (average mu = 0.085, current mu = 0.041) allocation failure scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory 1: 0x1024d42dc node::Abort() [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 2: 0x1024d4464 node::errors::TryCatchScope::~TryCatchScope() [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 3: 0x102623bc0 v8::Utils::ReportOOMFailure(v8::internal::Isolate, char const, bool) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 4: 0x102623b54 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, bool) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 5: 0x1027a726c v8::internal::Heap::GarbageCollectionReasonToString(v8::internal::GarbageCollectionReason) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 6: 0x1027aa87c v8::internal::Heap::CollectSharedGarbage(v8::internal::GarbageCollectionReason) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 7: 0x1027a7a34 v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 8: 0x1027a535c v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 9: 0x1027b10d4 v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 10: 0x1027b1168 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 11: 0x102783ffc v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 12: 0x102abc100 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long, v8::internal::Isolate) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 13: 0x102dd078c Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_NoBuiltinExit [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 14: 0x10808c6b8 15: 0x108090ce8 16: 0x108d9680c 17: 0x107592908 18: 0x1075aa170 19: 0x107597cc8 20: 0x1075a97e0 21: 0x10759729c 22: 0x1075a97e0 23: 0x108817cf4 24: 0x108851e40 25: 0x1076d62bc 26: 0x1080a4cac 27: 0x108652b8c 28: 0x107338f74 29: 0x1087f9698 30: 0x108e9e3b4 31: 0x108a1d5f0 32: 0x108c75538 33: 0x10711f1d4 34: 0x10705856c 35: 0x1087bb5b8 36: 0x1070585a4 37: 0x1076ecefc 38: 0x10878eed8 39: 0x10878d7c0 40: 0x1088ade64 41: 0x10878d888 42: 0x10878bdc4 43: 0x10878bea8 44: 0x1088adf04 45: 0x10878bf54 46: 0x1088adf04 47: 0x10878bcd0 48: 0x10878d5dc 49: 0x10878d5dc 50: 0x1088adf04 51: 0x10878cd04 52: 0x10878e4e0 53: 0x10878bb30 54: 0x1088adf04 55: 0x10878bf54 56: 0x1088adf04 57: 0x10878bcd0 58: 0x10878d5dc 59: 0x10878d5dc 60: 0x1088ade64 61: 0x10878cd04 62: 0x10878cbd0 63: 0x1088adf04 64: 0x10878cd04 65: 0x10878e4e0 66: 0x10878c5b0 67: 0x1088ade64 68: 0x10878c4d0 69: 0x10878cc78 70: 0x1088adf04 71: 0x10878cd04 72: 0x10878e4e0 73: 0x10878c5b0 74: 0x1088ade64 75: 0x10878c4d0 76: 0x10878cc78 77: 0x1074a7060 78: 0x10705cdd4 79: 0x1086debe8 80: 0x1074747ac 81: 0x102d93a14 Builtins_AsyncFunctionAwaitResolveClosure [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 82: 0x102e188b8 Builtins_PromiseFulfillReactionJob [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 83: 0x102d85df4 Builtins_RunMicrotasks [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 84: 0x102d620e4 Builtins_JSRunMicrotasksEntry [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 85: 0x102733a1c v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 86: 0x102733e50 v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate, v8::internal::(anonymous namespace)::InvokeParams const&) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 87: 0x102733f3c v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate, v8::internal::MicrotaskQueue, v8::internal::MaybeHandle) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 88: 0x102756b78 v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 89: 0x10275740c v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 90: 0x102421db4 node::InternalCallbackScope::Close() [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 91: 0x10242248c node::InternalMakeCallback(node::Environment, v8::Local, v8::Local, v8::Local, int, v8::Local, node::async_context) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 92: 0x1024374c8 node::AsyncWrap::MakeCallback(v8::Local, int, v8::Local) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 93: 0x1024d85c4 node::fs::FSReqCallback::Resolve(v8::Local) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 94: 0x1024d95a4 node::fs::AfterScanDirWithTypes(uv_fs_s) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 95: 0x102d42794 uvwork_done [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 96: 0x102d45f30 uv__async_io [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 97: 0x102d57ca8 uvio_poll [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 98: 0x102d463c0 uv_run [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 99: 0x102422ccc node::SpinEventLoop(node::Environment) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 100: 0x10250d6e0 node::NodeMainInstance::Run(int, node::Environment) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 101: 0x10250d3ac node::NodeMainInstance::Run(node::EnvSerializeInfo const*) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 102: 0x1024a72e0 node::Start(int, char**) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node] 103: 0x19e2d7f28 start [/usr/lib/dyld]

plantain-00 commented 1 year ago

It seems an issue when checking a large codebase, this tool just checks every identifiers' type, so if your codebase is too large, it costs a lot. You can try adding includes: ['**/*.{ts,tsx}' in your tsconfig.json Related issue: https://github.com/plantain-00/type-coverage/issues/89#issuecomment-1109495007

plantain-00 commented 1 year ago

When https://github.com/dudykr/stc is ready, this tool may use it as type checker to improve performance. It may help improve this issue.

spaul1042 commented 1 year ago

includes: includes: ['*/.{ts,tsx}' produces the same error Also, the issue exists, even when I put this: { "include": ["*/.tsx"], }

inside tscofig.json

spaul1042 commented 1 year ago

@plantain-00 , I am really confused how the type-coverage rate calculation actually works I have the project structure as below:

src packages (inside src) folderA (inside packages) folderB (inside folderA)

where folderB is a package whose type-coverage rate I wanna calculate

Case 1) when I run type-coverage -p src/packages/folderA/folderB >> result is memory limit error Case 2) when I cd src, cd packages, cd folderA, after this when I run type-coverage -p folderB. >> result is a finite percentage value

Also for those packages where memory limit doesn't exceed , running commands from the root terminal and from nested terminals (file path not starting with ../) yield different output, which output should I consider ?

Can you please help me here?

spaul1042 commented 1 year ago

Also I just wanna confirm this

if I have a package in src/packages/folderA/folderB, where folderB is the package and I I am in terminal >> cd src, cd packages, cd folderA, cd folderB

After this if I run the command type-coverage -p . this will give me the correct type-coverage rate for the package folderB right?

plantain-00 commented 1 year ago

Also I just wanna confirm this

if I have a package in src/packages/folderA/folderB, where folderB is the package and I I am in terminal >> cd src, cd packages, cd folderA, cd folderB

After this if I run the command type-coverage -p . this will give me the correct type-coverage rate for the package folderB right?

Yes.