Changing themes in a running instance overflows memory over time.

[dvdmuckle]

Using the file browser, if you change the theme of eDEX-UI a number of times, it starts to slow down and eventually grinds to a halt with the message [17916:0100/000000.413673:FATAL:memory.cc(22)] Out of memory. size=262144. It appears that when reloading a theme, the previous session is still being saved in memory, or something like that. This takes a number of theme changes to trigger on a machine with 16gb of RAM, though a smaller machine like my 8gb laptop doesn't take many theme changes.

[GitSquared]

(related source code)

[gandf]

Each theme applied stay 3 process WmiPrvSE.exe running on Windows.
Run eDEX-UI and close it stay 3 WmiPrvSE.exe.
Bug is present even if you don't change theme.

[GitSquared]

Hold up, could that be a windows specific issue?

[gandf]

After others tests, several exe stay in live after change theme on Windows. I don't have tested on other OS. List on windows :

• conhost.exe
• cmd.exe
• NETSTAT.exe
• WMIC.exe or sometime replaced by WmiPrvSE.exe
  Change theme or close eDEX-UI don't release these processes if RAM is full.
  otherwise, it takes time but after close app release these processes.

[GitSquared]

Damned, that looks bad. Processes are related to systeminformation dependency i believe, but they should close.

Handling of node.js child processes on windows is a fucking unbearable mess and that's an understatement. Thanks for the detailed info, @gandf . I'll see what i can do.

[gandf]

This code create processes.
initMods();

This code should destroy processes but it doesn't do it before close app.
delete window.mods;

[GitSquared]

Yeah doing a namespace cleanup before shutting down is not a bad idea. Will implement this ASAP and see if it helps things.

[gandf]

I think, solution 2 can works with taskkill :
stackoverflow

[GitSquared]

@dvdmuckle Could you please confirm on which OS you first had the issue?

[dvdmuckle]

@GitSquared Fedora 28.

[GitSquared]

(self-note: fix by implementing a themeOverride var in the core thread with the renderer's theme loader asking for it at startup, and effectively replacing the current messy recreation of modules by a full page reload)