NewsForumsCodeLogsGallerySpecsSearch

Memory leak using CreateImage and FreeImage

Blitz3D Forums/Blitz3D Programming/Memory leak using CreateImage and FreeImage

Foppy(Posted 2006) [#1]
After updating my version of Blitz 3D from 1.87 to 1.93 (I was running behind) I noticed a slowdown in a game I am writing after playing for a minute or so, and not long after that the game would crash. The game was using CreateImage and FreeImage a lot (in fact it was using it too often, that has now been fixed, but I think the memory leak is still there, only smaller so that it would probably still crash the game in the end).

I wrote this test program:
Graphics(800,600)
SetBuffer(BackBuffer())

Global g_image

While(Not(KeyHit(1)))
	; delete existing image
	If (g_image) Then
		FreeImage(g_image)
		g_image = 0
	End If
	
	; create image
	g_image = CreateImage(100,20)
Wend

Running this program, which repeatedly creates an image after first deleting an existing image, memory disappears rather quickly. (I am using FreeRam and the ram counter goes down quickly when this program is running.) Running in debug mode, this results in a Memory Access Violation.

Could it be that this is a new problem in version 1.93, or am I doing something wrong here myself?

I am using version 1.93 of IDE, Linker and Runtime, on Windows XP.

Edit 1: the program showing the memory leak can be a bit smaller even, like this:
While(Not(KeyHit(1)))
	image = CreateImage(100,20)
	FreeImage(image)
Wend

Edit 2: Switching back to 1.87 makes the memory leak disappear.


Ross C(Posted 2006) [#2]
The memory allocated i believe, does not get freed really, i believe. It just gets loaded over the top of when required, so you won't notice, i don't think, any increase in memory. I may be wrong about this...


jfk EO-11110(Posted 2006) [#3]
Well, is the memory really occupied, or was it simply not carbage-collected? When you run this test app, how many bytes get lost every loop. What happens when the machine runs out of memory? Can you still start an other app parallel to the test app?

well whatever happens you should know that parallel processes on your machine may force a fragmentation of the ram, even and especially socalled ram-defragmentation.

Fragmentation is the nature of computer media and it doesn't make sense to fight it with deragmentation when you allocate and deallocate Ram that many times.
It would be better to create the images once then reuse them. At least that's a much better programming style.


Sledge(Posted 2006) [#4]

It would be better to create the images once then reuse them. At least that's a much better programming style.



Isn't it a bit odd that we don't tend to take that attitude with type instances?


Foppy(Posted 2006) [#5]
I now tried Blitz3D versions from 1.87 up to 1.93, and the memory leak appears for the first time in 1.93.

Running this
While(Not(KeyHit(1)))
	image = CreateImage(100,20)
	FreeImage(image)
Wend
results in a MAV after 10 seconds.

It would be better to create the images once then reuse them. At least that's a much better programming style.
Yes that would be possible in my case. I am using this in a bitmap font system. When the player has a new score, the old image is replaced by a new one, and as you say I could instead re-use the old image and just clear it and redraw the score.

However in principle there shouldn't be a problem, and there was no problem in earlier versions of Blitz.


Ross C(Posted 2006) [#6]
I have no problems with that code. The VRAM usuage stays the same. Nothing decreases... using 1.91


Ross C(Posted 2006) [#7]
Yep, this is def a problem with 1.93.


Ross C(Posted 2006) [#8]
Posted a bug report about this.


jfk EO-11110(Posted 2006) [#9]
10 seconds?!? OMG! That's pretty fatal. I still use 1.91, so I didn't notice anything.


Foppy(Posted 2006) [#10]
Well, 10 or maybe 20 seconds, and of course it also depends on the size of the images being created and the memory available in the first place, but just to give an idea...


John Blackledge(Posted 2006) [#11]
Yeah, no problem with v1.91 -just the usual system memory juggling by Windows.