|
Potential Memory Leak? |
Posted by Ingmar on Sep-04-2011 10:44 |
|
Hi,
I am using ChartDirector 5.0.2 (C++), and I suspect a memory leak. Our application is generating charts (based on performance alerts), and we have noticed that it is (albeit very slowly) leaking memory.
In an effort to get to the source of the issue, we are using umdh.exe to find the leak. Umdh has identified the largest leak, which seems to come from chartdir50.dll:
+ 4d400 ( 5b8a0 - e4a0) 76f allocs BackTrace1EE858
+ 104 ( 76f - 66b) BackTrace1EE858 allocations
ntdll!RtlAllocateHeap+00000274
chartdir50!CImageMapHandler_destroy+0005E679
Since we don't have a debug build, the information is probably of limited usefulness, but I'm curious if you can assist anyway?
Another allocation leak we see is:
+ 3560 ( b030 - 7ad0) 2e7 allocs BackTrace1EF17C
+ 5f ( 2e7 - 288) BackTrace1EF17C allocations
ntdll!RtlAllocateHeap+00000274
chartdir50!CImageMapHandler_destroy+0005E679
chartdir50!CImageMapHandler_destroy+0005E570
There are more, but those are the largest ones. Currently we're only using the XYCharts. I'd be happy to send more information if needed.
Thank you. |
Re: Potential Memory Leak? |
Posted by Peter Kwan on Sep-06-2011 00:50 |
|
Hi Ingmar,
If what you found is some memory that is being allocated, but never freed, then it may not be a memory leak.
In fact, according to Micorsoft knowledge base, leaks detected my UMDH may not be actual leaks. It is normal for many programs (included many Microsoft programs) to allocate memory but do not free them. The memory may be used for various purpose, such as for cache. In fact, ChartDirector uses memory as font cache.
See:
http://support.microsoft.com/kb/268343
As according to the above knowledge base, the correct method to detect leaks is to use the Performance Monitor to monitor "Private Bytes under the Process category for your application". If the leak is very slow, it may be difficult to know if it is an actual leak or leak. In this case, the knowledge base suggest you to use an iteration to repeat the code many times. If you see the Private Bytes increases without bound, then there is leak. If the Private Bytes do not increase beyond a certain value, then there is no leak.
After you have confirmed there is a leak, you may then use UMDH to locate the leak.
In case you are not aware, the location "chartdir50!CImageMapHandler_destroy+0005E570" means the leak is located 0005E570 bytes from "!CImageMapHandler_destroy". The leak may or may not be in ChartDirector. What happened is that UMDH finds a potential leak at a certain address. but it cannot find the symbol for that address. The nearest symbol it can find is CImageMapHandler_destroy (which in this case is still very far away from the actual leak). So it uses "chartdir50!CImageMapHandler_destroy+0005E570" as the address of the leak.
If you suspect there is a leak in ChartDirector, to confirm and diagnose the problem, it is best to create a standalone program with ChartDirector code only. This ensures it is not the other part of the system that is leaking memory. I suggest you may use the "Simple Bar Chart" sample code, and modify it so it resembles your chart configuration. Then you may use a loop to run the code many times. We often test our code by repeating the charting code for 10000 to 100000 times. (The number of iteration is large enough that we can see any leaks quickly, and small enough so it can finish in a few minutes.) If there is a leak in the charting code, repeating it by 10000 times should result in 10000 leaks.
If after testing, you confirm there is a leak, is it possible to send the test code to me?
Hope this can help.
Regards
Peter Kwan |
|