The only thing there is to say about a 4 year old game developing a memory leak

[AdmiralTigerclaw]

To be clear for those who come in later and don't know:

A memory leak refers to an instance of a program allocating RAM (memory) for its own use, and then failing to 'release' or 'free' that RAM when it is no longer in use.  As a simple case, the program says "I want to store the value '100' as an integer in RAM."  The integer value '100' uses four bytes of ram.  A memory leak occurs when the program fails to say "I am no longer using the memory address storing the value '100'."  So the address is held and the four bytes don't get freed.  The program then wants to store the value '100' again.  But it allocates NEW ram (4 more bytes) to store it for a time.  It then fails to release THOSE four bytes, so now the program has 8 bytes of RAM allocated that it has not released.  Repeat?  12 bytes.  Again?  16 bytes.  You see where this is going.

The RAM is 'leaking' slowly as the program fails to clean up unused data and release the RAM. 

 

The Memory leak does NOT, by itself, cause any form of program crash.  Zero.  None.  It is not possible.

What happens, and has been happening in 32 bit KSP, is that the memory leak slowly eats up the available addressing allocation of a program that has a 32 bit memory address.  (Which is approximately 4 gigabytes).  When the 4 gig limit is reached, the program stack overflows (circles back around to zero), and tries to write into memory it first allocated.  The moment it does that, it writes into critical memory addresses allocated when the program first fired up that are likely being used for very core functions.  That causes a Bad Time in the program and the OS immediately detects this, goes 'Lol-NO.' and kills it without any warning at all.  This is a standard Crash To Desktop. or CTD.  If the code engine supporting the program is decent, the code engine catches this first and self-terminates while spitting out a crash report.  This is the kind of crash that generates a big 'I R broken.' message.

 

With 64 bit KSP, the 64 bit address size for memory means you have more allocation for memory than any system on the planet has actual memory.  It's not going to stack overflow addresses for a long, long time.  What will happen instead is that your computer will just use more and more RAM until it eats all available ram and proceeds to turn to virtual ram (use your hard drive as more RAM)...  which is slow.  Like, you know when it's using the HDD for it.  EVERYTHING is slow.  Horribly slow.  Like, pre-Pentium slow.  By the time this would crash the program, your computer is so busy making read-writes to the hard drive, that the OS itself already crashed from insufficient resources, or you've manually rebooted the PC via the RESET or POWER buttons (or in some rare cases, a quick plug-socket recoupling).

 

The biggest cause of sudden random crashes, however is ICFS (I Can't Find S*@!).  Much like how the stack overflow causes a CTD because it corrupts a memory address and the OS kills it before Bad Things can happen, a coding bug can also result in problems with values stored to memory.  A big one is code looking for a value that was never placed into memory, or was cleaned up early and no longer exists.  If the program looks for an address that isn't allocated, well, it doesn't know WHAT to do if there's nothing (null) there.  Best case scenario, a leftover junk value at that memory address gets used and you get a freak event in the program.  Worst case, there's a click, a blink, and you're staring at a Blue Screen of Death... Which means something screwed up so hard the OS itself threw in the towel and said 'Just reboot'.  These days, however, operating systems have gotten really good about catching and killing such events by forcing the program itself to terminate.  Thus, the rampant CTD incidents where you do something, and the program just... goes away.

 

When trying to isolate a bug from a CTD, always try to remember the EXACT thing you did the very instant the program blinks and vanishes, and the exact sequence of events leading up to it.  This is down to the click, and sometimes even something in the background, like a music loop resetting or something new being generated on the display, can likewise be a culprit.  The sequence of events is absolutely vital, as you can think of it like exiting off an interstate and crossing a river.  You can't find out the bridge is out if you don't take exit 452 and turn RIGHT.  If you take exit 453, you cross a different bridge.  You turn left, you never cross, or you turn around, go back to exit 451 and cross at an earlier bridge.

It also helps that if you find your bug culprit and isolate it, to play around a bit and see if similar actions or alternate steps still set it off.  Sometimes you learn that what you think is the problem, is actually not the problem, but is instead, just one instance of a separate problem you just happened to trigger.  Like, for example, if the program crashes every time I type '100'.  I would check if it crashes if I type '1', if I type '0', if I type '00', or '10'.  Then I could learn that maybe, oh, it's not '100' that causes the crash, it's any number containing '1'.  Which in this case, would be '100', '1', and '10'.  I would then also try typing numbers like 2, 3, etc... or letters/other characters.  I would also check if the program crashes if I type '000' or '111' to rule out if it's three numbers.  Since all programming is just sophisticated patterns, pattern association and recognition is a crucial skillset to bring to bear.

 

And I just chattered for an hour to write this...  How silly is that?