David_Bat_Masterson@cup.portal.com (03/16/88)
Is there any programs around that will sweep through memory for unused, but not "free" memory (memory for some reason or another should be on the free list, but didn't make it there)? Often after I run programs, I find that the Workbench memory indicator shows less memory than when I started the programs. This does not happen all the time, even when using the same program (perhaps I did something different inside the program). Sometimes this memory loss can be upwards of 70K-80K, but, since I have 3Meg of memory on an B2000, I haven't been paying much attention to this "loss". I was hoping there was a program that might collect up blocks of memory that other programs did not release properly. Does such a thing exist? David Masterson DMasterson@cup.portal.com
cmcmanis%pepper@Sun.COM (Chuck McManis) (03/17/88)
Memory leaks are a nasty problem and everyone should check to see that their program gives back all the memory it takes. In article <3909@cup.portal.com> David_Bat_Masterson@cup.portal.com writes: > Is there any programs around that will sweep through memory for unused, but > not "free" memory (memory for some reason or another should be on the free > list, but didn't make it there)? The mechanics of this aren't to tough to write, but how do you propose to determine if memory is 'supposed' to be free? There is no description of task address spaces so there is no way to determine who 'owns' the memory. > Often after I run programs, I find that >the Workbench memory indicator shows less memory than when I started the >programs. This does not happen all the time, even when using the same >program (perhaps I did something different inside the program). Sometimes >this memory loss can be upwards of 70K-80K, but, since I have 3Meg of memory >on an B2000, I haven't been paying much attention to this "loss". Sometimes programs bring fonts or libraries into memory when they run, these are not immediatly freed because some other program may want to use them. The next time a memory request comes through requesting more memory than is available then they will be expunged. A little known option on the workbench is the 'debug' switch. If you start workbench in your cli with the line : LoadWB -debug Then an invisible menu will appear after the 'Special' menu header. One of its options is 'flush libs' which will flush out any libraries that aren't being used but are still resident in ram. So try running your program, then flush libs, and then check to see if the same amount of memory is available as before. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
kenchiu@phoenix.Princeton.EDU (Kenneth Chiu) (03/17/88)
In article <3909@cup.portal.com> David_Bat_Masterson@cup.portal.com writes: >Is there any programs around that will sweep through memory for unused, but >not "free" memory (memory for some reason or another should be on the free >list, but didn't make it there)? The system doesn't save enough information to do this. You would have to do some major hacking. >Often after I run programs, I find that >the Workbench memory indicator shows less memory than when I started the >programs. This does not happen all the time, even when using the same >program (perhaps I did something different inside the program). This does not necessarily mean the program is at fault. It could be a library or device it opened up. This could still be left in memory at termination. Also, some amount of overhead is used by Intuition to maintain the windows. This overhead is not minimized as often as it could. So the memory could still be eaten up even though the screen looks the same as when the program started. Another way to check is to run the program twice in a row. Don't play with the windows any. Then compare after the first run and after the second run. Ken Chiu
keithd@cadovax.UUCP (Keith Doyle) (03/19/88)
In article <45779@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >Memory leaks are a nasty problem and everyone should check to see that >their program gives back all the memory it takes. Speaking of which, this latest report of an Intuition bug that leaves a TempA allocated when doing overlapping Blit's. Can a program safely deallocate it itself? Or will this break once the Intuition bug is fixed? I would think if we check for a non-NULL pointer there, we can deallocate it, future Intuition rev's making sure they NULL the pointer if they deallocate it automatically in the future. Keith Doyle # {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170
cks@radio.toronto.edu (Chris Siebenmann) (03/22/88)
In article <2002@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: ... >Speaking of which, this latest report of an Intuition bug that leaves >a TempA allocated when doing overlapping Blit's. Can a program safely >deallocate it itself? The main problem with this is finding the memory the graphics library allocated for the tempA. No pointer to it is returned, and it seems unlikely that we'd find one hanging around. I also hope that this bug will be fixed in the next release; in the mean time, it's easy to avoid in programs you write (just allocate the tempA yourself). -- You're a prisoner of the dark sky/The propeller blades are still And the evil eye of the hurricane's/Coming in for the kill Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks cks@radio.toronto.edu or ...!utgpu!{chp!hak!ziebmef,ontmoh}!cks