ID:155615
 
Memory leaks, real? or fiction? I'm kidding. I know they're real. Now what exactly are they and how can they be stopped?

For one, I've noticed that in some games dream seeker starts off using about 70,000K or so to begin with, and many many hours later (like 10+) can turn into almost 700,000. Is this just how byond is or is it coding error? If it is actual error, which it probably is, what exactly would you look for when fixing it?
It's possible that Dreamseeker/Dreamdaemon is leaking memory, but in practice this is a programming mistake.

Creating objects and never deleting them or letting them be garbage collected will cause a 'memory leak'. For example, the following DM leaks memory (Assuming there's a tile at 1,1,1):

mob/verb/test()
spawn()
while(1)
new /obj(locate(1, 1, 1))
sleep()


That's because it's creating /objs, and while they're still in the world they won't be deleted.

Other potential places you can make similar mistakes are adding things to lists and never removing them (either by letting the list get deleted or explicitly removing them), or having strings that keep growing. Those two are effectively bounded because there is a list and string size limit (I think?)
In response to Jp (#1)
Most data types in DM are references, and most references have a limit of around 16 million. (A small few have lower bounds of 64K but for the most part that has been increased.) But even within a 64K limit you can run into trouble by not letting objects get deleted.

One thing I see a lot is that people will assign a list var to an obj or a mob, thinking nothing of it, but they'll initialize that list at compile-time--so that every time the object is created, a copy of the list is created as well.

The server has a few caches it uses for icon operations, but in principle those should never get that big. The client has caches it uses for icons that it is displaying, but it has a garbage collector that will unload those icons after a while.

Lummox JR
In response to Jp (#1)
Jp wrote:
Other potential places you can make similar mistakes are adding things to lists and never removing them (either by letting the list get deleted or explicitly removing them), or having strings that keep growing. Those two are effectively bounded because there is a list and string size limit (I think?)

This one sounds more likely.

Thanks, both of you. I think I have a few ideas of where there might be problems. To remedy would lists created in verbs need to be deleted? Or do the things put in the list need to be removed from the list instead of just deleted while in it?
In response to VcentG (#3)
If you create a list during a verb and it's only around temporarily, then the list will be deleted on its own when the verb ends, and the references to everything in it will be decremented. For example, this will never leak:

mob/proc/NoLeak()
var/list/L = list(src, loc)
for(var/item in L) src << L


The list has a reference count of 1 when the proc ends, and the proc ending will reduce that to 0. The reference counts of src and loc will also be reduced. No leak.

This will leak:

mob/proc/Leak()
var/list/L1 = list(0)
var/list/L2 = list(0)
L1[1] = L2
L2[1] = L1


Both lists now contain a reference to each other. When the proc ends, L1 and L2 are still referenced, so they will continue to exist. Even though nothing else in the world references them except each other, BYOND can't detect this kind of cycle and so it just leaves them alone. They'll persist until you reboot the server, or until you locate() one of them with a reference and delete it (or in this case, empty it, either of which will break the cycle).

Lummox JR