memoryleak=FreeGadget()

BlitzMax Forums/BlitzMax Programming/memoryleak=FreeGadget()

Banshee

(Posted 2007) [#1]

I'm finding that I am getting a memory leak with the FreeGadget command. Even a simple test program such as this will see the ram usage spiral at a steady and uncomfortable rate.

Global hello:TGadget
Global window:TGadget
window=CreateWindow("World",0,0,200,200)

Repeat
	createanddelete()
Until KeyDown(KEY_ESCAPE)

Function createanddelete()
	hello=CreateButton("hello",0,0,100,100,window)
	FreeGadget hello
End Function

Am I doing something wrong? When I delete a gadget I wish to utterly destroy it, I think BlitzMax is keeping it in memory incase it is re-used but when I reuse the same gadget a new instance is made anyway, or something.

I've tried doing GCCollect manually, but it doesnt make a difference.

I'm compiling using Intel Mac OS X version of Blitz Max.

Thank you.

Damien Sturdy

(Posted 2007) [#2]

out of question, what happens when you use "Hello=null"?

Banshee

(Posted 2007) [#3]

oh sorry I missed that off the sample code but it's the same as that is what I am doing in my actual application.

Azathoth

(Posted 2007) [#4]

Shouldn't need to, hello is constantly being over written anyway.

SebHoll

(Posted 2007) [#5]

Tell us what happens when you insert a PollSystem() after the CreateButton() and FreeGadget() command, i.e.

Global hello:TGadget
Global window:TGadget
window=CreateWindow("World",0,0,200,200)

Repeat
	createanddelete()
Until KeyDown(KEY_ESCAPE)

Function createanddelete()
	hello=CreateButton("hello",0,0,100,100,window)
	PollSystem()
	FreeGadget hello
	PollSystem()
End Function

The thing to note about Cocoa (OS X's GUI Library) is that many of the GUI commands only execute upon a call to PollSystem() which is usually called by WaitEvent() in a standard event driven BlitzMax app.

Banshee

(Posted 2007) [#6]

Even on your code Seb, memory usage keeps rising at a rate of a couple of mb a minute.

It strikes me that there appears to be a memory leak in the MaxGUI with the OS X module?

EDIT: 17mb to 25mb in the time it took to write the above :)

SebHoll

(Posted 2007) [#7]

I suggest you post this in the MaxGUI bug reports - although Skid's probably really busy right now with Axe.Win32MaxGUI development, this is quite a severe memory leave. Make sure you specify your CPU architecture (PPC/Intel) and the version number of Brl.CocoaMaxGUI from the Modinfo part of the docs, just in case.

I'll check if I get the same results on my G3 later if it decides to boot (its on its last legs ;-) ). Mind you, there are quite a few Cocoa bugs stacking up in that Bug Report forum.

Banshee

(Posted 2007) [#8]

Cheers, posted ( http://www.blitzmax.com/Community/posts.php?topic=70301 ) at least from this post I can rest easier knowing it's not me miss-understanding BlitzMax - some things about this compiler still confuse me!

:)

peltazoid

(Posted 2007) [#9]

Hi, I added a call to GCMemAllocated and checked for max ram used at anyone point and it ceilings at around 32 meg, although it is fluctuating between 17 and 32MB but never gets any higher than 32MB

This is what I changed

If GCMemAlloced() > usedram
		usedram = GCMemAlloced() 
	End If
SetStatusText(window, usedram)

This is on PC with latest sync-mods and V1.24

Cheers.

Banshee

(Posted 2007) [#10]

I'm running seb's version of the code here and watching the memory usage in the Mac equivellent of Task Manager (Activity Monitor) and so far i'm up to 49mb and it's still steadily rising.

I believe this is a memory leak specific to the OS X version of the GUI module, so PC tests aren't really proving/disproving the problem other than proving it's specific to OSX. :)

51mb now...