Hi,
We have an application whose virtual memory rises and keep going for over a day. After two days it has climbed to about 500MB. I have tried profiling the applications which hits a database as well as makes lots of http and soap requests but I Fastmm4 shows there are no leaks.
I am not sure how or when memory is claimed and if there is a problem here with the rising virtual memory?
JD
Shot into the dark: Does your app implement a cache of some sorts? A cache with a bad policy is another name for a memory leak.
You could try some profiler apps that can trace what type of objects are allocated at a point, or you can even make your own tool to dump allocated objects. Don't wanna make publicity but we have use AQTime quite successfully.
it might not be "Leaking" memory, and be more "Hoarding" it. Memory isn't Leaked until the application cannot release it. e.g. after it's pointer is lost.
Memory is claimed when an object is created and freed when the object is destroyed (or lost if the object overwritten with a new object). A leak is when the memory is never freed (After the application has been closed). It may be a case of an object not being freed during the applications run, but if the object is added to a list or array of objects then the list/array just keeps growing (instead of overwriting), If the objects are owned by the application they automatically free when the application closes, but not until the application closes, FastMM has nothing to report since no memory has been leaked (it has all been free'd when the app closed)
A Memory profiler can show the number of each object currently in memory as well the Objects class (we also use AQ Time which does this). You'll need to look at the memory profile after an hour/2 hours /3 hours. Most long running apps (all that I know of) have a fairly constant (long term) memory requirement, and each of the objects in memory also remain fairly constant. Obviously there will probably be spikes when the app is busy but these should return back to a stable level. Have a look to see if any of the object counts are growing continuosly.
My bet is that the app is dynamically creating something with either a form or Application as it's parent, adding it at the end of a list, and not freeing it. The object sits in memory until the app is closed, but each new object requires more memory.
Last but not least there can also be a heap fragmentation issue. This is much less likely with FastMM4, but it could be wise to check it anyway.
The easiest solution is to log somewhere in the app the stats of the heapmanager (getheapstatus), and check if the FreeBig and FreeSmall are not the bulk of your missing memory. If so, then heapfragmentation is your main problem.
The Totalallocated field contains the amount of memory used by the program. If this is high, you are using the memory, but freeing it on shutdown.
That could be anything, including e.g. periodically logging some info to a memo or tstringlist.
Some well placed logging of totalallocated while shutting down might help identify where the memory is left.
We have had a similar problem with our middle tier servers on Win2008.
If by any chance you are using MDAC (ADO) on Windows 2008 server (or Win7) and doing a lot of Connections, there is a leak in the MS code that scrubs the Connection info.
From MS: "The leak happens in some security code that is used to remove things like passwords from connection strings. A work around may be to include the following in the connection string, “Persist Security Info=true”."