Memory Leaks - Causes?
BlitzMax Forums/BlitzMax Programming/Memory Leaks - Causes?
| ||
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... |
| ||
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. |
| ||
So there may be some leaks on 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. |
| ||
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. 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 you run the app for a longer time, you'll see that memory usage levels off. 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 |
| ||
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... |