Possible memory leak in idle app

[akhenry]

Steps to reproduce

1. Navigate to the app's default route (eg. http://localhost:8080/#). You should be taken to My Items, a folder view.
2. In dev tools go the timeline tab, and hit record
3. Trigger garbage collection (the trash can in the Timeline tab)
4. Wait a while and do nothing (~100s should do it). It's important to keep the tab in focus though, otherwise setTimeouts won't happen.
5. Trigger garbage collection again
6. Heap does not return to original usage. Instead, looks something like this -

Sawtooth shape is due to regular minor garbage collections. Additionally there is one full GC at the start triggered manually, and two full GCs (triggered twice manually for good measure) at the end. Despite the two full GCs heap allocation does not return to its original size.

[evenstensberg]

• https://github.com/andywer/leakage

[larkin]

Pretty sure this is the sinewave generator, which accidentally keeps references to unsubscribe functions.

[unlikelyzero]

This is still an issue

[scottbell]

I left "My Items" running for ~30 minutes, and 805 kbytes of new memory was allocated (big blue line before is garbage collection):

Here's the heap snapshot:
Heap-20220624T143929.heaptimeline.zip

[scottbell]

Ran it again and saw ~350 kbytes of growth over ~30 minutes:

Heap-20220624T154733.heaptimeline.zip

@akhenry looks pretty minimal to me?

[unlikelyzero]

@scottbell we have an automated test for this. Let's sync out of band

[akhenry]

Running it in dev mode will always leak some amount of memory. Both Webpack HMR and Chrome dev tools are known to leak memory. @johnhill2 Did you observe the memory leak locally or in a production environment?

It's probably worth repeating this with a prod build (vanilla Open MCT is fine, doesn't need to be one of our deployments) so HMR isn't a factor. I bet those arrays are full of Webpack stuff.

[unlikelyzero]

@akhenry production environment on hulk during the STM Devsims on root folder menu

[scottbell]

In production mode, memory was more flat:

42 kbytes/hour, so possibly 504 kbytes/12 hours
The application reserves 69.4 mb, so this would be 0.7% growth over 12 hours, which I think is within our tolerances, right @akhenry? I've attached the big fat heap dump:
Heap-20220701T164516.zip

[akhenry]

@scottbell within tolerances, yup. Let's close this for now.