>Does anyone know the common causes of memory leaks? I am using PG and am >getting hit pretty bad and have no idea what is causing this. I know it is >me and not PG but can't figure it out. Is there a way to find where the >memory leaks are? A memory leak means: 1) Somewhere in your program you are allocating memory dynamically (NewHandle, NewPtr). 2) Nowhere in your program are you throwing it away. You can find such a leak simply by doing the same thing over and over and over again, watching the thermometer in "About This Mac". If the bar keeps creeping inexorably upward, you have a leak. This may not be the problem. Often a "leak" is simply a matter of using various parts of the program, which load up structures they need once - then discovering that there is not enough memory in the program's partition to store everything that's needed. (You can sometimes work around this with temporary memory, which is a nice solution anyway.) Typically, there are not a huge number of routines that call NewHandle or NewPtr. Memory leaks in this case are a result of not clearly defining whose responsibility the memory is and when it is to be thrown away. In an event-driven programming model, this can sometimes be confusing. Try writing down a description of which part of your program owns the memory, under what circumstances it is to be created, and under what circumstances it is to be disposed. If you can't clearly define this, then it is a good bet that somehow the memory is leaking away. GET FIELD, PICTURE OFF, READ FIELD, and the various INDEX$ statements all allocate memory. Check to make sure the handles these routines allocate aren't slipping away unnoticed. Also look for things like grabbing a colour icon with GETCICON, but not throwing it away with DISPOSECICON (A cicon handle in memory is a complex structure with sub-handles; you can dispose of the icon handle itself, but that creates a memory leak.), or similar things with gworlds and such structures. Automatic memory management is _so_ nice... -Mars