In my precedent articles that I've published concerning the memory leaks (C++ memory leak check on x64 platform and test of different tools and How to filter Intel XE Inspector results), I was talking about the fact that for huge programs like Sophis Risque, the debugging using such tools is quite difficult to do. In fact, in some cases, I've found no tool that can do the job as I wanted. Using a tool like Intel Inspector gives sometimes so many errors that it is quite difficult to detect the real problem. That's why I've developped one tool that permits to detect easy bugs without impacting the whole performance during all the test but just for a piece of code that could interest me. The goal of this post is to present this tool.

Even on x64 OS environment, it is not interesting to let the process using all the available memory. In some cases, like on CITRIX servers, the fact that one user consumes a lot of quantity will impact all users too. The goal of this post is to analyze all the possibilities that gives the MS SDK, in order to capture either bad memory allocation or to limit the process to a certain quantity of RAM.

When developing an executable, there are several solutions to follow the memory consumption on a process. A third party performance monitor could be used in order to store the information and follow the memory growth on the time. I know some like Sysload, provided by Orsyp.

Another solution is to dump the memory used at different steps of the process in some log files and using this log files to make some statistics.

An easy way to resolve it is to use tis to increase the maximum heap size by using JVM options -Xmx512M. This will immediately solve your OutOfMemoryError.

For example, using the following command with the XSLT processor (Saxon Java):

Intel Inspector is a C++ development tool that can be used to detect memory leaks and corruption.

Using this tool and when trying to detect memory leaks in our library, which uses the Misys Sophis toolkit, a lot of memory leaks are found, due to the fact that memory cache used by Sophis or our toolkit library are not correctly released: about 4000 are displayed after analysis. Using existing filters provided by the tool is not sufficient in order to detect which are relevant or not.

The subject of this post is then to provide methods which permit to filter memory leaks which are not due to a cache or static data allocated in the loaded dll's.

After a migration from x86 to x64 on Misys Risque, one of the biggest deal was to find a tool able to check the memory leaks and access violations (buffer overrun and so on..). This was done one year ago, but I think that nothing has been changed since. I tested different tools and this is the results of my analysis: