memory leak

BlitzMax Forums/BlitzMax Programming/memory leak

Gillissie(Posted 2008) [#1]
I am new to BlitzMax, so I wanted to experiment with the garbage collection idea to make sure I understand how it works to avoid memory leaks. In my first basic example, there appears to be a memory leak.

SuperStrict

Type ta
	Field a%,b%,c%
End Type

Type tb
	Field a:ta
End Type

GCCollect()
Print "0 Objects: " + GCMemAlloced()

Local b:tb = New tb

GCCollect()
Print "1 Objects: " + GCMemAlloced()

b.a = New ta

GCCollect()
Print "2 Objects: " + GCMemAlloced()

b.a = Null  ' comment this for even more leakage, since b.a apparently isn't collected after b is collected below. Or maybe b isn't being collected at all?

GCCollect()
Print "1 Objects: " + GCMemAlloced()

b = Null

GCCollect()
Print "0 Objects: " + GCMemAlloced()



skidracer(Posted 2008) [#2]
Strings are objects too.

Blitz GC is both I think incremental in nature and hard to predict at the best of times, that doesn't make it bad, it just makes it fast.

Also, putting your code in a loop shows it doesn't leak.


dmaz(Posted 2008) [#3]
people are way to freaked out and misinformed about this leak stuff. there is no leak in your code above even if you comment out those lines. the GC in blitz does it's job as it sees fit at the time.... just because you call GCCollect yourself, it doesn't mean those things are ready for collection.

there are few reasons to null your variables at all in blitz. the ref counter will take care of this just find as it does in your code above. you really only have to null cyclic references.(when one object points to another and that object points back)

As skid said, put it in a loop....




GaryV(Posted 2008) [#4]
The GC in BlitzMax does take a little getting used to, but in my experience, it is rock solid.


MGE(Posted 2008) [#5]
"you really only have to null cyclic references. When one object points to another and that object points back"

Amen to that. :)


Gillissie(Posted 2008) [#6]
What I was trying to figure out when I first set up this test is whether I need to set object properties to null before the object itself is set to null (whether manually or automatically by falling out of scope).

The docs say that you still need to manually remove list items or they will never go away. Is this true? What if I have a list object as a property to another object that goes away? Does the list of objects still exist? Example:

type mytype
  field mylist:TList
end type

a:mytype = new mytype
a.mylist = new TList
ListAddLast a.mylist,"Something"

a = null  ' does this clean up the list and objects in it?



Gabriel(Posted 2008) [#7]
When the docs refer to list items, they mean items *in* a list. The list itself is marked for collection when the object it is in ceases to exist. I think it's just trying to make it clear that all the time you have a list with items in it, those items will not be collected.


Brucey(Posted 2008) [#8]
An object will be marked for deletion when it is no longer in scope and not referred to by any other object.

It may not be cleaned up immediately, but it will eventually, when the garbage collector decides.

When a list is deleted, any items in the list will have their reference count lowered by 1. If that means that now no other objects refer to the item, it will also be marked for deletion... and so on.