Memory leakage in OpenMovie!!
BlitzPlus Forums/BlitzPlus Programming/Memory leakage in OpenMovie!!
| ||
| It seems that in Blitz 1.83 there is leakage of videomemory when using OpenMovie/CloseMovie. Here is the test code. ========================================= ; This example shows the leakage of videomemory when using ; OpenMovie / CloseMvie commands. Graphics 800,600,16 SetBuffer FrontBuffer() fntArial=LoadFont("Arial",24,False,False,False) SetFont fntArial a0 = AvailVidMem() For i = 0 To 10 m = OpenMovie("avi\m_27.avi ") ; m = OpenMovie("Graphics\l01_0006.gif") CloseMovie m Next diff = a0 - AvailVidMem() Text 100, 100, "diff = " + diff WaitKey() End ========================================= For .avi file it gives more than 10 Mb difference, for .gif -- about 0.44 Mb (both in non-debug mode). Does anyone know how to overcome this problem? Or, maybe, someone can suggest the way to free all videomemory? Mikle. |
| ||
| Either way, I'd report it in the bug reports forum, not here. With that excellent code example, mark should hopefully be able to pin the leak down fairly quickly... |
| ||
| I think this is just the way Blitz manages video memory. Even though you free the movie the memory is not freed until you need it for something else. |
| ||
| Floyd, Does "something else" mean reusing videomemory for the next OpenMovie? If so, then memory leakage in the example should constantly be about 1 MB (the value reported after one run of OpenMovie). But it is 10 Mb... I don't know what will happen if I open/close movie 100 times. At least this example shows me that all videomemory will be exhausted (diff = 63 MB)! I’ve sent the letter to Mark, but he did not answer :-(( Mikle. |
| ||
| Try opening and closing a big movie, say several Mb, a hundred times. Then open it one more time and play it with DrawMovie. It should work. The only problem here is that you can't tell how much video memory is really available. I suppose this could be considered a bug in AvailVidMem(). |
| ||
| I think there is a question of whether Blitz automatically releases the memory back to the operating system after you make the effort to release if from within your program. It the thinking is that it is unnecessary to release the memory right away, only to possibly need it again, then by holding onto the memory for awhile would tend to improve overall performance. And Blitz really does not need to take any more action regarding that released memory when it is released - after all, if you are not going to use it any mofe, why should you care? It only needs to do housekeeping at the start when it acquires and assigns the memory. Many years ago, there was a debate in the software community about whether "housecleaning" should be done at the start of a program, the end of a program, or both. It could be shown that doing it at the end had a fatal flaw: Not all programs ran to normal termination, and those that failed, left an untidy mess of assigned resources and memory that other programs had to resolve before they could run. But the debate between those that wanted to clean up only at the start and those that wanted to also clean up at the end, continued. The first were economists: What was the point? The second were, by nature, just tidy. In a single-user system environment, a lot of programmers were probably unaware that this had been an issue. So most programs initialized variables, assigned constants, created arrays, and requested memory and ran. When they stopped, that was it. Nothing to it. Wut it has been my understanding that Windows has requrired that good programming practice do some cleanup when the programs end. They release resources, including ports and memory, before they go away. "Memory leaks" occur when they don't do that. This has been an ongoing issue with programs written in C and C++, because the programmer is in full control, and has full responsibility, of all the activity performed (or neglected) by his or her program. One of the key things done by BASIC and Java is that they cleanup is done automatically by the process that is created by the compiler. But note that your program is still running, so the final cleanup is not involved. Instead, what you are probably looking at is an accounting error - Blitz is not experiencing a memory leak, per se, but it is not giving you the expected value back when you query it about the amount of memory available to you. That might be a bug, but technically, it is not a memory leak. If you (or anyone else) finds that you are running out of memory, or resources, and your PC slows to the point of a crall or stops entirely, and your CPU meter pegs at 100%, then that can be induced in part by a memory leak, from one or more applications that are failing to terminate properly. While you cannot fix the applications themselves, there are several things you can do to reduce or eliminate the problem. (1) Check your Virtual Memory settings under System in the Control Panel, (2) Add more memory to your system, especially if you have less than 256 MBytes, (3) Install a third party resource and memory manager, such as TurboMem or Memory Zipper, among others. These programs check how Windows is assigning memory and resources, and if they find a discrepancy between what is assigned, and the absence of the application that initially requested it. they then instruct Windows to release the resource or memory on behalf of the departed application. They generally do a good job at this, so you have to judge which is best by what else they claim to do and the reviews that they get. I don't mind saying that I've really liked Memory Zipper (also called MemZip) after trying some other products, simply because it seems to be a bit more thorough, give you lots of tweaks to play with (and default settings for different preferences), and acutally beat a couple of competitors in the number of simultaneous applications I could have open at once. But this is not a pitch for a specific product - I'm just trying to clue anyone in as to how to deal with related problems if your search has brought you here. Do your own online search and there is plenty of information available on the subject. |
   |