Since September 2012, there is a very simple but comfortable way to find FastMM memory leaks in Delphi applications which do not show up at program termination.This type of memory leakis normally not easy to track down, as it is caused by global objects which will be properly freed at the end of the program execution, but slowly increase their count at run time, causing resource expiration after a while. FastMM4991 introduced a new method which allows to find this type of leak.
Read the full answer on Stackoverflow.
To discover the leak at run time, you only need these steps:
- add a call to
LogMemoryManagerStateToFile('memory.log', '')in a place where it will be called in intervals
- run the application
- open the log file with a tail program (for example BareTail), which will auto-refresh when the file content changes
- watch the first lines of the file, they will contain the memory allocations which occupy the highest amount of memory
- if you see a class or memory type constantly has a growing number of instances, this can be the reason of your leak