That's not what a memory leak is. Even if that definition were accurate, the data in the event log is never garbage data—it's meaningful data of dubious usefulness.
A memory leak is the result of memory that has not been properly deallocated and is effectively lost. When you have to manage your own memory it's exceedingly easy to create a memory leak. Here's an example in C:
C:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv) {
leaky_pp();
return 0;
}
void leaky_pp() {
char *str;
str = malloc(sizeof(char) * 13);
strcpy(str, "Hello world!");
printf("%s\n", str);
/* MEMORY LEAK: str is never freed! */
}
This example leaks 13 bytes of memory. When
leaky_pp() is called, it allocates 13 bytes to hold the "Hello world!" string. The function is returned, but the memory is never frees. Since C doesn't do automatic reference counting or garbage collection, this memory remains allocated and is effectively unusable after the function returns and the pointer falls out of scope*. If
leaky_pp() is called again, another 13 bytes will be leaked, as the subsequent
malloc() call will allocate
another 13 bytes of memory.
In this case it isn't a big deal, since the OS will clean up its memory after the program terminates. What if we were to throw the function call in a while loop, creating the traditional looping "Hello world!" program? Every single iteration would cause 13 bytes of memory to be allocated and would eventually run the system out of memory.
That's what a memory leak is. "Hello world!", for this application, was never garbage data. It's data that sticks around for far longer than intended due to a lack of an explicit deallocation. If you were writing a typical C#/Java application (and LT is just a typical Java application, large as it may be) the garbage collector would ensure that memory isn't lost like this.
To be clear, it's still possible to end up in this situation with managed languages but you have to go out of your way to do it. In C# you can cause a memory leak by calling a function like
Marshal.AllocHGlobal() and not subsequently calling
Marshal.FreeHGlobal() (or by P/Invoking
malloc from the C library). It's not something someone is liable to do by accident while writing a typical application.
Either way (and yes, I know I'm being pedantic), what's happening in LT isn't a memory leak. It's simply that the event log was uncapped and would eventually grow to stupidly large sizes.
*It technically can be used and even freed later on, but that would require knowing its memory address. It's not particularly feasible to attain that after the fact.
