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!
spaul1042 opened this issue · 6 comments
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::MaybeHandlev8::internal::Object) [/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::Localv8::Object, v8::Localv8::Object, v8::Localv8::Function, int, v8::Localv8::Value, node::async_context) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node]
92: 0x1024374c8 node::AsyncWrap::MakeCallback(v8::Localv8::Function, int, v8::Localv8::Value) [/Users/spaul2/.nvm/versions/node/v16.15.0/bin/node]
93: 0x1024d85c4 node::fs::FSReqCallback::Resolve(v8::Localv8::Value) [/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 uv__work_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 uv__io_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]
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: #89 (comment)
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.
includes: includes: ['/*.{ts,tsx}' produces the same error
Also, the issue exists, even when I put this:
{
"include": ["/*.tsx"],
}
inside tscofig.json
@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?
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?
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 folderBAfter this if I run the command
type-coverage -p .this will give me the correct type-coverage rate for the package folderB right?
Yes.