My apps got a number of screens, and when I flip between a couple of screens, task manager shows my applications memory usage goes up by a megabyte or more.
I've been profiling my application, and there appears to be little in the way of addtiional managed objects appearing (just a few strings and other miscelaneous stuff that doesn't look important). But, I've been using SciTech's memory profiler, and that shows me that native memory is being allocated. From the stack traces it shows me, it looks like the chart control is losing memory.
I've created a simple sample application (attached) that appears to exhibit the problem.
Steps to Reproduce:
Run the application and look at its memory usage in task manager. Every time the button is hit, when task manager updates, it shows that the amount of memory used by the application goes up.
The delta between the two snapshots shows that there is some outstanding heap memory that has been allocated.
See the "stack traces.txt" file in the attached zip for a list of the stack traces that lead to memory being allocated that doesn't appear to be being freed.
Allocated memory should be released.
Further information: A collegue running XP also sees a similar amount of memory being consumed. This bug was reported by a customer beta testing our software, I'm trying to get details of their platform. I could be wrong, but I find it doubtful that we've all got the same faulty graphics driver installed.
If you haven't already, please could you veryify whether or not memory leaks for you when trying the sample application I created?
The Task Memory shows all memory allocated for your process, while the GC.GetTotalMemory() method returns only the amount of managed memory allocated. You can find all necessary information about GC in MSDN library. Please go to : http://msdn2.microsoft.com/en-us/library/ms954591.aspx. Windows can reclaim memory if another process requires this.
I've modified your sample to use the GC.GetTotalMemory() method. Please try the sample from the attachment and let us know the results.
GC.GetTotalMemory() behaves as you say. Your modifications tell me that managed memory usage isn't going up. This is in agreement with the original description I raised.
However, that is not the problem! The problem is that native memory usage is going up. It appears that the chart control uses the unmanaged OpenGL library via interop. I suspect that some call to OpenGl that allocates memory (maybe the one to WGL.CreateContext in file Graphics.cs) isn't being matched with a corresponding call to free the memory. I'm currently trying to build your XtraChart dlls from the source in debug mode to inspect this.
I've debugged it now. Try these steps:
Remove the for loop from the sample applications program.cs file so that the form only shows once.
Added the DevExpress.XtraCharts project to the solution.
Set breakpoints in Graphics.cs on the following two lines:
hglrc = WGL.CreateContext(hdc);
Run the application, and when the form appears close it again.
Some breakpoints will have been hit. CreateContext runs 3 times, but DeleteContext only runs 2 times. This means there was one call to CreateContext that caused memory/resources to be allocated that weren't cleaned up again. I'm still trying to determine why this is.
ChartControl.InitializeDrawing checks that openGLGraphics == null, and then calls GetDC. This causes ChartControl.OnHandleCreated to be called, and that calls ChartControl.InitializeDrawing again! So, there's some reentrancy going on there, that I'm pretty sure the original author didn't intend or expect. This means that ChartControl.InitializeDrawing calls chart.CreateNativeGraphics twice... and this results in two OpenGLGraphics.CreateContext calls when I believe that only 1 was intended.
Normally, although this isn't correct, it wouldn't have result in a leak if OpenGL graphics IDisposable interface had been implemented correctly, but it isn't. The finalizer is missing... it needs to be implemented to at least call Dispose, and should probably be done in a standard way as described here: http://msdn.microsoft.com/en-us/library/ms244737(VS.80).aspx
I'd recommend you fix both problems:
Implement IDisposable correctly for class OpenGLGraphics, and
Stop the reentrancy problem from causing double calls to chart.CreateNativeGraphics in the first place.
And maybe you'd better check all of your other classes that have unmanaged resources to ensure Dispose has been implemented correctly for them!
I added this:
to the end of class OpenGLGraphics, and retried my sample application, and the now Task Manager doesn't report increasing memory everytime the form opens and closes.
The problem I've got now is that our ship date for this product is Friday. Can you please tell me when you expect to have this fixed, and do you grant permissions for us to patch and ship a version of your assembly that we've fixed and built ourselves?
Thank you for the update. We've fixed a similar issue with the 2008.2 version of the suite.
Could you please update your project to the 2008.2.4 version of the suite and let us know how it goes with this version (you can download this version via the Client Center).
Please let us know your results.
Can you give me a link to the similar issue so I can look at that please?
Unfortunately we are shipping our product very shortly, it is therefore not possible for us to upgrade to an entirely new version of your suite as there are probably many changes included in it and it would be too risky to upgrade in case this introduces more problems. So, I will find a workaround for now, but hope to have this resolved for our next release.
From the way you worded your reply, I get the impression that you have not made an attempt to verify whether the new version you mention does actually resolve this issue or not, and that you are expecting me to do this work for you. Ordinarily I would be happy to do this, but to be honest, I think I've already spent quite a bit of time trying to get to the bottom of this issue. Also, it appears that your previous suggestions have been complete guesses and I was very suprised you didn't even bother to try the sample application (that took me some time to create) before you made your initial response, so I am skeptical as to whether this suggestion is another complete guess or not. This is why I would like to see the similar issue you believe may be a duplicate of this one.
By continually closing this issue as 'by design', you are starting to make me think that your company intentionally designs memory leaks into your product!
The problem and the solution to it have absolutely nothing to do with the graphics card driver.
My graphics card isn't even an ATI card, I've got an Intel GMA 950.
I never mentioned the graphics card, and don't think there is any problem with it or the driver.
Is the specific problem I have explained in detail resolved, or are you still trying to fob me off?
I have upgraded to version 8.3.3
I have retested the issue using the original sample application that I attached to this issue. It still clearly exhibits the exact same problem.
Neither of the specific code errors I identified in my post dated 10/7/2008 3:03:17 PM have been addressed.
Can this issue please be escalated.
Could you please clarify the version of the Intel GMA 950 drivers you're using?
Please refer to the http://downloadmirror.intel.com/14875/ENG/Graphics%20Media%20Accelerator%20Driver%20Production%20Version%2015.6.1.1329%20relnotes_gfx.htm article (BugID: 2437347, 2440454).
My device is:
Mobile Intel(R) 945 Express Chipset Family
Driver Version: 18.104.22.1687
The intel bug description does not fit the symptoms of the problem I'm experiencing. The intel bug refers to a kernel memory leak, which this is not. Also, as I've already said, this problem has been experienced on a number of different computers, and it's extremely doubtful they have the same graphics card fault.
I am at a loss as to understand why you keep talking about graphics cards when, as explained, I have pin-pointed the problem down to a software bug in your chart control code.
I am now extremely unsatisfied with the support I am receiving on this issue. Please find a programmer who has responsibility for maintaining the DevExpress.XtraCharts and ask them to review this issue.
The onus is on you to explain why the 2 specific problems I described with your code are not problems. If you cannot describe why they are not problems, then they ARE, and if your company has any kind of professionalism then you should see to it that they are promptly fixed.
I will be most upset if you try and push this back on to me without giving it the necessary investigation required. I spent a long time investigating and tracking down the cause of the memory leak, and it is highly frustrating that you are not prepared to look into it or even acknowledge that there is a flaw in your product. It should have been DevExpress who spent the time tracking down the flaw, not me.
I'm sorry to hear about the problem you're experiencing with our suite.
I've tested your project on a number of machines, but your issue isn't replicating.
Please review the attachment. It contains a screencast, and the modified sample project, illustrating these statements.
I've contacted our XtraChart developer prior to sending answer to you.
Please try to install the 22.214.171.1248 drivers : http://downloadcenter.intel.com/filter_results.aspx?strTypes=all&ProductID=2996&OSFullName=Windows+Vista*+Enterprise%2C+32-bit+version&lang=eng&strOSs=155&submit=Go!
and let us know the results.
Thanks for the screencast. I see that you have altered the sample application I sent to display the amount of managed memory each time the button is hit. It is true, this value doesn't go up. That is because it is not managed memory that is leaking. It is unmanaged memory that is leaking. I have updated the sample to display this value alongside the managed memory value and returned it to you.
You will see that the difference in managed memory stabilizes after hitting the button a couple of times, but will also see that unmanaged memory continues to go up every time the button is hit.
You can verify that this problem is caused by the chart control by removing the chart control from the form and running the program again. If you run it without the chart control, both managed and unmanaged memory stabilize after a few button clicks.
Thankyou for contacting the XtraChart developer. Did you just discuss the problem with him/her or did they have the opportunity to read the issue? Could you please send the following text to the developer verbatim:
in the file: C:\Program Files\Developer Express .NET v8.3\Sources\DevExpress.XtraCharts\DevExpress.XtraCharts.UI\ChartControl.cs
in the method: InitializeDrawing
on line: 744
The call to GetDC causes the method ChartControl.OnHandleCreated to be executed. The OnHandleCreated method calls InitializeDrawing a second time. This means that when InitializeDrawing is called once... it actually executes twice. Because it executes twice, CreateNativeGraphics on line 747 executes twice when it should only execute once. The unexpected second execution is the cause of an unmanaged memory leak.
If the developer puts a breakpoint on line 747 of the ChartControl.cs file and runs the sample application, they will see it executes twice instead of once.
I am in the process of updating the graphics driver on my computer. If that makes any difference to the memory leak I will notify you immediately.
I tried to install the 126.96.36.1998 drivers you refered me to. However, they don't support my chipset. They support the G45 Express Chipset Family. My computer has the 945GM Express Chipset. But, I did find the latest driver for my chipset and upgraded to that. It is version PV15.8.3 (188.8.131.524).
I ran the sample application, and the memory leak still exists.
Thank you for the detailed explanation, and please accept out apology for this issue.
Indeed, we've not fixed this problem in version 2008.3 of the suite.
For now, we've added the required changes, and I've uploaded a temporary build for you. You can install it from this thread.
Please try it, and let us know the results.
I am glad to hear that the problem has been resolved. Thank you for letting us know of your progress.
If everything goes according to plan we will release version 2008.3.5 of the suite this March.
Please feel free to contact us if you need any additional assistance. We will be happy to help you.
Is your intention to post an answer to your own question?
- If so, then proceed.
- If you simply wanted to post additional information, ask for further clarification, or to just say "Thanks!", please click Leave a Comment.
- If you wish to edit your original question, please use the Edit button in the Toolbox at the top right corner of that entry.