Memory Leaks - Causes?

BlitzMax Forums/BlitzMax Programming/Memory Leaks - Causes?

thalamus(Posted 2009) [#1]
I noticed in the Task Manager that my current app's memory requirement keeps trickling upwards, even when the program is idle.

What are common causes of memory leaks in Blitz? I've tried to use good housekeeping methods but I'm at a loss as to why it's such a memory hog...


markcw(Posted 2009) [#2]
I assume you mean MaxGUI. I just fixed a memory leak in fltkmaxgui, almost to be expected in fltk except that this wasn't fltk code. So there may be some leaks on win/mac too.

I would suggest you try to track it down by building sample apps and seeing which ones leak, it may be specific to a gadget.


Brucey(Posted 2009) [#3]
So there may be some leaks on win/mac too.

I should hope not. I spent far too much time plugging them! :-p

Non-GUI related... The default GC will appear to "leak" a certain amount of memory, when you run an app for a short time. But in reality this is more like having a bin which fills up and is then freed at some point during GC collection.
If you run the app for a longer time, you'll see that memory usage levels off.

Otherwise, you might have circular references in your code, which cause objects you think should be GC'd, to hang around for ever. That is a memory leak in the proper sense.


dmaz(Posted 2009) [#4]
Non-GUI related... The default GC will appear to "leak" a certain amount of memory, when you run an app for a short time. But in reality this is more like having a bin which fills up and is then freed at some point during GC collection.
If you run the app for a longer time, you'll see that memory usage levels off.
I don't think that should characterized as a "leak" even with quotes because it's really not. I think that just confuses people.

if your app keeps growing then like Brucey suggested, you most likely have a circular reference somewhere. that happens when an object points to another object that points back to the first. in such a case the object's reference count won't go to zero when it's out of scope until you break the chain. you do that manually by nulling the pointer.

in my projects I watch for leaks all the time as I'm developing, with code similar to below. it very simply prints the current allocated mem and the max allocated mem. if the max continues to climb when I don't expect it to then I have a leak. running the code below should allow you to see the GC's mem deallocation pattern and how it levels off after many iterations.
SuperStrict

Graphics 640,480

Global peakMem:Int
While Not KeyHit(KEY_ESCAPE)
	Cls
	
	Local currentMem:Int = GCMemAlloced()
	If currentMem > peakMem Then peakMem = currentMem
	
	DrawText currentMem+" -> "+peakMem,10,10
	
	Flip
Wend

my machine levels off at 87202


Grey Alien(Posted 2009) [#5]
I believe I may know what this is if a) you are using Vista and b) you are using OpenAL as your sound driver. I'm just about to post a thread about it...