JavaScript heap out of memory error while compiling Typescript code

[bonifacyj]

Hey everyone! I've added this piece of code to the typescript/react project:

public static async readFile(file: File) {
    cornerstoneWADOImageLoader.external.cornerstone = cornerstone;
    const imageID = cornerstoneWADOImageLoader.wadouri.fileManager.add(file);
    const image: Image = await cornerstone.loadImage(imageID);
    return new this(image);
}

constructor(public image: Image) {
    this.data = image.getPixelData();
    this.header = new DICOMImageHeader(image);
}

... and it seems to generate a memory leak to the extend that compiler crashes with FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

I'll attach a node-generated report to the issue, maybe it will be helpful :) report.20200412.103356.9148.0.001.json.zip

And this is the full cli output: <--- Last few GCs --->

[9148:000001ECE79B2D20] 138135 ms: Mark-sweep 2046.6 (2051.1) -> 2045.7 (2051.1) MB, 2663.9 / 0.1 ms (average mu = 0.131, current mu = 0.122) allocation failure scavenge might not succeed [9148:000001ECE79B2D20] 141053 ms: Mark-sweep 2046.7 (2051.3) -> 2045.8 (2051.3) MB, 2446.9 / 0.1 ms (average mu = 0.145, current mu = 0.161) allocation failure scavenge might not succeed

<--- JS stacktrace --->

==== JS stack trace =========================================

0: ExitFrame [pc: 00007FF756944DDD]

Security context: 0x01190ec808d1 <JSObject> 1: SourceMapConsumer_allGeneratedPositionsFor [0000039194F469D1] [C:\Users\bonifacyj\Documents\HPI\BP-CL\classifai\ui\node_modules\react-scripts\node_modules\source-map\lib\source-map-consumer.js:~178] [pc=000003F5F073B4EF](this=0x003bac4801a9 <BasicSourceMapConsumer map = 000002DAEDF7FD69>,0x0086cbc40161 <Object map = 000002DAEDF4BCE9>) 2: /* anon...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Writing Node.js report to file: report.20200412.103356.9148.0.001.json Node.js report completed 1: 00007FF755D4363F napi_wrap+128063 2: 00007FF755CE2836 public: bool __cdecl v8::base::CPU::has_sse(void)const __ptr64+35142 3: 00007FF755CE34F6 public: bool __cdecl v8::base::CPU::has_sse(void)const __ptr64+38406 4: 00007FF7564F9F4E private: void __cdecl v8::Isolate::ReportExternalAllocationLimitReached(void) __ptr64+94 5: 00007FF7564E2021 public: class v8::SharedArrayBuffer::Contents __cdecl v8::SharedArrayBuffer::Externalize(void) __ptr64+833 6: 00007FF7563AE57C public: static void __cdecl v8::internal::Heap::EphemeronKeyWriteBarrierFromCode(unsigned __int64,unsigned __int64,class v8::internal::Isolate * __ptr64)+1436 7: 00007FF7563B97D0 public: void __cdecl v8::internal::Heap::ProtectUnprotectedMemoryChunks(void) __ptr64+1312 8: 00007FF7563B62F4 public: static bool __cdecl v8::internal::Heap::PageFlagsAreConsistent(class v8::internal::HeapObject)+3204 9: 00007FF7563ABB13 public: bool __cdecl v8::internal::Heap::CollectGarbage(enum v8::internal::AllocationSpace,enum v8::internal::GarbageCollectionReason,enum v8::GCCallbackFlags) __ptr64+1283 10: 00007FF7563AA184 public: void __cdecl v8::internal::Heap::AddRetainedMap(class v8::internal::Handle<class v8::internal::Map>) __ptr64+2452 11: 00007FF7563CB36D public: class v8::internal::Handle<class v8::internal::HeapObject> __cdecl v8::internal::Factory::NewFillerObject(int,bool,enum v8::internal::AllocationType,enum v8::internal::AllocationOrigin) __ptr64+61
12: 00007FF756130C51 public: class v8::internal::interpreter::JumpTableTargetOffsets::iterator & __ptr64 __cdecl v8::internal::interpreter::JumpTableTargetOffsets::iterator::operator=(class v8::internal::interpreter::JumpTableTargetOffsets::iterator && __ptr64) __ptr64+1665 13: 00007FF756944DDD public: virtual bool __cdecl v8::internal::SetupIsolateDelegate::SetupHeap(class v8::internal::Heap * __ptr64) __ptr64+546637 14: 000003F5F073B4EF error Command failed with exit code 134.

Have you ever seen things like that happen before? Maybe someone with an experience using the library with typescript? Would appreciate any feedback.

[dannyrb]

I'm pretty sure this is because we bundle our codecs in version 3+. We'll likely need to "split" and pull these in as they're needed for decoding. Having them as separate bundles makes it easier to make sure the bundler doesn't pull them in.

I'm all ears for recommended approaches, or for PRs to improve this bit of functionality. Identifying a good one-size-fits-all solution has been challenging.