Pinning down a memory leak (?)

[AccidentalDisassembly]

On my heavily-modded install of

KSP: 0.90, Win 32 version

OS: Win 8.1 Enterprise x64

Install location: C:\Games\KSPNew\

Mods installed: see picture below

*I believe* all mods are up to date, but this has happened for a while and has not changed as I have updated mods as they're released.

...when I load the game, I use about 2.3GB of RAM when first arriving at the KSC screen. However, after a while playing, invariably I run out of memory.

No, I am not using ATM - instead, I converted basically every texture in GameData to DDS using DDS4KSP (except for ones whose conversion caused problems/crashes, such as a couple in NearFutureSolar), resizing them to 0.5x dimensions (or smaller). I found this gave me more RAM savings than ATM.

I would assume that different scenes, different numbers of parts in view, more or less flights, and all that sort of thing would make memory vary - and it does vary, but the trend is always upward. I would also assume that starting the game using 2.3GB is not really dangerous territory for running out of memory because of the number of parts I've loaded.

Number of scene switches (in and out of VAB, reverts, switching to different craft on the Mun or Minmus or whatever) *seems* to affect RAM usage, where switching scenes more = pushing the "baseline" of RAM usage higher and higher.

Likewise, loading a craft in the VAB (for example) will make RAM jump maybe 200MB or so, and then closing the VAB or hitting "new craft" will not result in that RAM usage going back down - it fluctuates, certainly, and sometimes by a lot, but the trend is upward. If I load a craft when 2800MB of RAM is in use (for instance), usage will jump to 3.0GB and never go back under 2900MB or so even when I leave the VAB and change scenes a bunch of times. Loading craft in VAB/SPH *seems* to be the single biggest contributor, since I noticed large jumps in memory use when doing so.

Is there any way to pin down what (or which mod) is causing this phenomenon? I would like to be able to actually play for more than 30 mins or so without running out of memory on an install that really seems like it shouldn't.

Here's a log: https://dl.dropboxusercontent.com/u/59567837/output_logMemoryLeak.txt

In that log, I was able to crash the game due to being out of memory by doing nothing but switching between scenes / vessels (on the Mun and Minmus), returning to the KSC, loading vehicles in the VAB and SPH. Did not launch anything, did not do any science, etc.

And here's a screenshot of my GameData folder (EriksParts contains random, one-off parts from certain mods I liked but didn't want every part from - no DLLs in there):

Note that I have deleted many, many parts from the larger parts packs (like KW, B9, NovaPunch) in order to save RAM, so I'm not actually trying to run all of those mods at the same time, really.

Edited December 29, 2014 by AccidentalDisassembly

[kerbiloid]

(Just ideas.)

As it's generally acknowledged that KSP loads all assets at once on the game start, the problem is not in additional loading of something.

As while playing the RAM usage continuously increases until the game crash, we can say that the game releases memory blocks more slowly than allocates the new ones.

As while staying inside VAB we can load/create and destroy ships a hundred times per game session with no crash and with more or less constant RAM usage, so game objects are definitely destroyed by the game engine when become unreferenced.

So, as C# memory management is based on a garbage collector - a "subprocess" which periodically checks which objects have become unreferenced and releases unused memory blocks, we can presume that:

- When we are in VAB, the new objects are being created slowly - just on mouse clicks. The garbage collector from time to time checks the memory and releases unused memory - ad infinitum.

- When we are playing, say, on a simple ship landed on a planet, new objects are also not created too fast. The game can last for hours.

- When we are playing actively moving (launching/docking/landing) among multiple objects, the new objects are created too fast, and Garbage Collector just lags to release all destroyed objects (as the new ones are created in real time, while GC runs from time to time).

That's just my vision, maybe erroneous.

[AccidentalDisassembly]

(Just ideas.)

As it's generally acknowledged that KSP loads all assets at once on the game start, the problem is not in additional loading of something.

As while playing the RAM usage continuously increases until the game crash, we can say that the game releases memory blocks more slowly than allocates the new ones.

As while staying inside VAB we can load/create and destroy ships a hundred times per game session with no crash and with more or less constant RAM usage, so game objects are definitely destroyed by the game engine when become unreferenced.

So, as C# memory management is based on a garbage collector - a "subprocess" which periodically checks which objects have become unreferenced and releases unused memory blocks, we can presume that:

- When we are in VAB, the new objects are being created slowly - just on mouse clicks. The garbage collector from time to time checks the memory and releases unused memory - ad infinitum.

- When we are playing, say, on a simple ship landed on a planet, new objects are also not created too fast. The game can last for hours.

- When we are playing actively moving (launching/docking/landing) among multiple objects, the new objects are created too fast, and Garbage Collector just lags to release all destroyed objects (as the new ones are created in real time, while GC runs from time to time).

That's just my vision, maybe erroneous.

I don't know much about programming, but it sounds plausible - however, I can't stay inside the VAB and load/create/destroy ad infinitum, or at least I am pretty sure I can't. The more I load/new/load/new etc., the more ram is used. Usage does vary, but it trends upward.

Is there any way to figure out what's going on? I am at my wits' end, I just want to play (with the mods I have chosen and which don't push me anywhere near the memory limit initially). =(

[Jebadiah Kerban]

Hi.

Could i please have the log?

also i would like to know:

Ram_GB_:

Hard_drive space free:

FPS:

also every mod uses 100MB of ram at least to run so if you have 20 mods you will need 6.2GB of ram with 2 GB hard_drivespace free

[Rasip]

also every mod uses 100MB of ram at least to run

Where did you get that number? I've got 34 mods running right now and am only at 1.4GB. By your math i should be using 3.3GB just for the mods.

OP, the memory leak is in KSP itself. Over 90% of the out of memory crashes I've seen have been while loading into the VAB.

[Jebadiah Kerban]

Where did you get that number? I've got 34 mods running right now and am only at 1.4GB. By your math i should be using 3.3GB just for the mods.

OP, the memory leak is in KSP itself. Over 90% of the out of memory crashes I've seen have been while loading into the VAB. so that means im dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb dumb

Too many mods then or some ids are the same

[AccidentalDisassembly]

Hi.

Could i please have the log?

Too many mods then or some ids are the same

The log is linked in my post. The word "log" is even in bold. I don't have too many mods - I start at 2.3GB used, and it simply goes up from there without installing any more mods - just by playing, and especially by loading craft in the VAB/SPH. Nothing gets unloaded, maybe. I don't know.

OP, the memory leak is in KSP itself.

Man, I hope Squad will look at memory use in KSP, if that's the case. EDIT: Unless it's a Unity thing, in which case I hope they'll write many angry letters. It seems rather important to address memory leaks and memory usage more generally in a game that derives most of its lasting interest (and its proselytizing fans) from the ability to mod it, which takes memory, of course.

Edited January 2, 2015 by AccidentalDisassembly