Memory hole in chat output?

[Weissrolf]

FGU only releases memory once my total system memory usage hits 98%. At first it only releases small parts, but after maybe half a minute it drops all the way down to more sane numbers.

The following tests did doing nothing but repeated /roll d20.

[LordEntrails]

What's the elapsed time that the 20k rolls are being done? If you allow the 5 minute save to interrupt, does the chat memory get cleaned up then? Or is their another interval time when the cleanup happens?

[seansps]

I am glad to see someone else did the research and posted the evidence. I was planning on doing the same, because it seems clear to me there *is* a memory leak somewhere and that the chat is related, but is not the full story.

I've been wanting to report this for a while because it very much is an issue. I've noticed that after the 3 hour mark in my games, there is a LOT of lag, and it becomes unbearable for some users. I am not talking about 5-min interval save lag (I had that before and fixed it with a new campaign and exporting all my custom stuff to modules.). This is lag that results from constant use of FG over time, which is indicative of a memory leak and greatly impacts our game.

I've noticed the only sure way to fix it is to close FG and restart, and have everyone to re-log in. (Also indicative of mem leaks). It's very disruptive... so I hope it can be fixed!

Edit: Adding that clearing the chat HELPS a little bit, but not a lot, the lag still prevails. Only truly fixed by the above.

[Weissrolf]

For the /roll D20 test FGU starts its memory management more properly, releasing memory constantly in small bits. Unfortunately the general trend is still upwards, but with usage always going up and down the climb is slow(er).



Saving db.xml is the turning point, but (seemingly) only when FGU is busy running the /roll D20 test while saving the database file (more testing needed by developers themselves). If the file is saved during a pause then memory management seems to stay the same as shown above. If the file is saved while the dice are rolled then memory management breaks down and usage starts climbing in a rather steep curve (considering that we only roll dice).



Furthermore, after over 130k rolls I saw FGU freeze (the last two crashes happened when I was not at the computer). I noticed that the GUIs of all other running applications (including Explorer) went down, too, either crashing or showing graphical glitches. My guess is that an exploding number of open handles is the reason. Usually handles stay below 100k for me, mostly around 70-80k. But when the freeze happened they were well over 200k.



Handles did not increase while I recorded the memory increase you saw in the above animated GIFs. So there seems to be another catastrophic failure point later in time at which this happens.

[Weissrolf]

Next let's take a look at the chat input field and input history being a hot mess that may or may not be responsible for the memory shenanigans posted earlier.

The longer the text you paste into the chat input field the more sluggish its response becomes. And once you press Enter the sluggishness permanently stays until you exit to the Lobby or restart. If you delete the input string before hitting Enter then chat instantly becomes responsive again.

But the worse problem is memory consumption and memory leaking again. Pasting 10 mio. chars (less than 10 mb!) into the chat input results in FGU's memory consumption increasing by 5100 mb (5 gb)! That is before hitting Enter to fill the input history.



Most of this memory is never released until you restart FGU, not even when you exit to the Lobby.



So chat input eats memory. This happens from the get-go, so saving of db.xml is irrelevant to this (or maybe it gets even worse then? didn't check).

For comparison, here is pasting the same 10k chars into Note:



PS: This is a good point to mention huge memory consumption for loading images again. FGU needs many times more memory than (uncompressed 24 bit) images sizes to load these. I am not convinced that FGU should compare to Photoshop where memory consumption is concerned.

[Weissrolf]

The increase in handles is just a side-effect (caused by Taskhostw.exe). The main issue is with virtual memory, which FGU fills completely and then shoots down various running applications due to being maxed out. The latest W10 and W11 seem to max out at 64 gb virtual memory when set to Auto (default) on both my 16 gb systems.



I manually set the maximum to 128000 mb, which resulted in this:



This is not exactly news, of course.

[Weissrolf]

By increasing maximum virtual memory to 160000 mb I managed to not have FGU crash while rolling dice overnight. But at one point there still must have been (memory) problems, because like before FGU started outputting some of these lines after some time:

<font color="##660066">GM: </font> [d8-1 = -1]<br />

So rolling a D8-1 resulted in numbers from-1 to 7 instead of 0 to 7. I saw that before and it only seems to happen once memory consumption starts making problems.

[Weissrolf]

Rolling D8 for a living:

[Weissrolf]

10 Minutes later:



13 Minutes later:

[Weissrolf]

Closing the FGU application: