Originally Posted By: Riamus2
Uptime shouldn't be the cause,

I don't think anyone was suggesting that uptime was the cause, but if the script is leaking data as was suggested, uptime is definitely going to be a factor. It's therefore useful to show uptime for reference. If the footprint is 800mb only 30 minutes into running the program, the behaviour might be a feature of the script rather than a bug (i.e. it loads some large database into memory instead of reading off disk). If it takes a week to get to that point, the script is likely storing more data into memory over time at a fast rate, and it's possible that the author didn't take into account long running processes or clearing out old memory.

Memory usage shouldn't change no matter how long mIRC is running, but a script can easily make memory usage increase over time. Consider a script that logs every line of text to a hash table-- eventually you will grow a large memory footprint, though it would likely be on the order of years, not months. Now imagine a poorly written script that stores that same line 5 times in different tables, or has some kind of exponential data growth. Now we're talking weeks/months instead of years.

By the way, just as a note, we shouldn't rule out a leak in mIRC. It's completely possible that some obscure order of commands could cause mIRC to allocate memory and lose it rather than free it when the script ends; this bug could have been exposed by the script.

- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"